Approach · Quality & security
Quality & security.
Quality engineering, secure development and evidence that supports the decisions the organisation has to make.
Quality is a property of the delivery system.
Quality is produced by the way work is defined, reviewed, tested, deployed and operated; it cannot be inspected in at the end of a release. A group that treats testing as a phase will always be testing under pressure.
The same is true of security. A penetration test can reveal a weakness, but it cannot create a secure design. Security has to be part of the architecture, the code, the pipeline and the operating model.
Our quality and security approach is built around evidence: what was reviewed, what was tested, what was found and what was done about it. The evidence is proportional to the risk, but it is never invented after the fact.
Built into the path, not added at the end.
We use the smallest set of controls that gives confidence in the change, then increase the rigour where the consequence is higher.
Code review
Every production change is reviewed for correctness, maintainability, security and fit with the architecture. Review is a conversation, not a rubber stamp.
Automated testing
Unit, integration and end-to-end tests cover the behaviour that matters. Tests are maintained as part of the codebase, not treated as a one-off project.
Continuous integration
Repeatable builds, static checks and test execution on every change. A build that only works on one machine is not a build process.
Environment control
Development, test, staging and production are separated. Configuration is managed, not edited by hand and remembered.
Release management
Releases are planned, reversible and communicated. Database changes, feature flags and rollback steps are part of the release, not an afterthought.
Observability
Logs, metrics, traces and alerting are designed so that the system can be understood in normal and degraded operation.
Secure by design.
Security begins with a threat model and a data map. We identify the assets, the actors, the trust boundaries and the failure modes, then define controls that address the actual risk.
Identity and access
Least privilege, role separation, strong authentication and auditable access. Privileged access is limited, reviewed and logged.
Data handling
Data is classified, minimised and protected in transit and at rest. Retention and deletion rules are defined and implemented, not left to individual practice.
Secure development
Dependencies are managed, secrets are kept out of code, input is validated and output is encoded. Security checks run as part of the pipeline.
Vulnerability management
Findings are triaged by severity and exploitability, assigned an owner and tracked to remediation. A report that nobody actions is not a control.
Incident response
Roles, escalation, communication and evidence preservation are agreed before an incident. Post-incident review focuses on cause and systemic improvement.
What we can evidence.
The evidence depends on the engagement, but the categories are consistent.
Architecture and threat model
Decision records, data map, trust boundaries, access model and risk register.
Code and test evidence
Review records, automated test results, static analysis, dependency scan and build provenance.
Release and monitoring evidence
Release approval, rollback plan, monitoring configuration, alert tests and incident records.
Quality and security questions.
Do you perform penetration testing?
We can coordinate independent penetration testing and remediate findings. We do not treat a single test as evidence that the system is secure.
How do you manage third-party dependencies?
Through a maintained inventory, vulnerability scanning, licence review and a defined update cadence. Critical vulnerabilities are assessed against exploitability and exposure.
What happens if a security issue is found after go-live?
It is triaged, contained and remediated under the agreed support model. The client is informed of the impact and the actions taken. Post-incident review addresses the cause.
Can you align to our security framework?
Yes. We map our controls and evidence to the client’s framework where required, provided the requirements are clear and the scope is agreed.
Assurance without theatre.
Assurance is the evidence that controls were designed, implemented, tested and operated, not a folder of screenshots produced at the end of a project. The evidence should be proportionate to the risk and useful to the people who have to make a decision.
- Design evidence: architecture records, threat model and data map.
- Build evidence: code review, automated tests and dependency checks.
- Release evidence: approval, rollback plan and environment verification.
- Operating evidence: monitoring, incidents, access reviews and test results.
We agree the evidence format with the client at the start. That avoids a last-minute scramble and ensures the evidence answers the questions the client’s risk, audit or procurement function will actually ask. A control that cannot be evidenced is difficult to defend, even when it exists.
Need quality and security evidence you can defend?
Tell us about the assurance requirements and the system. We will propose a proportionate approach.