What is secure development, and why fix the process rather than the finding?
Secure development means building security into how a team ships software — requirements, design, code, pipeline, infrastructure and operations — so that a class of vulnerability cannot come back next sprint. A penetration test tells you what is broken today; secure development keeps it from breaking again. We help engineering teams set this up the same way we run our own projects, following the practices of the NIST Secure Software Development Framework (SSDF).
The scale of the problem is in the dependencies, not just your code: Black Duck found that 84% of the codebases it audited contained at least one known open-source vulnerability, and 74% contained a high-risk one (Black Duck OSSRA, 2024). That is a pipeline problem, and pipelines are fixable.
What do we do?
We do six things, alone or as one programme: security code review, threat modelling, DevSecOps pipelines, cloud and Kubernetes hardening, application security architecture and a security engineer embedded in your team. Each one produces evidence you can show an auditor. Secret detection alone earns its place — GitGuardian counted 12.8 million new hard-coded secrets leaked in public GitHub commits in 2023, a 28% increase on the year before (GitGuardian, 2024).
- Security code review — manual review of authentication, authorisation, input handling, crypto and secrets in Python, PHP, JavaScript/TypeScript, Go, Swift and Kotlin codebases, backed by SAST.
- Threat modelling — STRIDE-style sessions on new features and architectures before they are built; a living threat register.
- DevSecOps pipeline — SAST, dependency and container scanning (SCA), secret detection, IaC scanning, DAST on staging, SBOM generation, signed builds; gates that block on severity without blocking the team.
- Cloud and Kubernetes hardening — CIS benchmarks, IAM least privilege, network policies, secrets management, logging and alerting, backup and restore drills.
- Application security architecture — SSO/OIDC, MFA, session and token design, multi-tenant isolation, encryption at rest and in transit, audit trails.
- Security engineer on your team — part-time or full-time, inside your sprints, under a monthly retainer.
SOC 2 vs ISO 27001: which should you go for first?
If your customers are mostly in North America and ask for "your SOC 2 report", start with SOC 2; if they are in Europe or ask for "your certificate", start with ISO/IEC 27001. The technical controls overlap heavily — access, change management, logging, vulnerability management, backup — so the engineering work we do serves both, and many companies end up with both.
| Criterion | SOC 2 | ISO/IEC 27001 |
|---|---|---|
| What it is | Attestation report by a CPA firm against the AICPA Trust Services Criteria | Certification of an information security management system (ISMS) by an accredited body |
| Scope | Security required; availability, confidentiality, processing integrity, privacy optional | Whole ISMS; 93 controls in Annex A of the 2022 edition |
| Output | Type I (point in time) or Type II (6–12 month period) report | Certificate valid 3 years with annual surveillance audits |
| Recognised mainly in | USA, SaaS buyers | Europe and global; often required in tenders |
| Typical effort | 3–9 months including observation period | 6–12 months including ISMS build-out |
Which compliance frameworks can we prepare you for?
We prepare engineering evidence for GDPR, ISO 27001, SOC 2, PCI DSS, DORA, NIS2 and the EU AI Act. We are engineers, not auditors — and that is the point: we translate a framework into concrete technical controls, implement them and produce the evidence an auditor asks for. Deadlines are real: GDPR gives you 72 hours to notify the supervisory authority of a personal-data breach (GDPR Art. 33, 2016), and DORA has applied to financial entities in the EU since 17 January 2025, including mandatory threat-led penetration testing for the larger ones (EU, 2022).
- GDPR — data mapping, minimisation, retention and deletion, DPIA support, DPA-ready processing design, breach-detection tooling.
- ISO 27001 / SOC 2 — gap assessment against Annex A / Trust Services Criteria, technical controls (access, change, logging, vulnerability management), policies drafted with your team.
- PCI DSS — scope reduction, segmentation, tokenisation, required scans and tests.
- DORA, NIS2 — ICT risk management, incident reporting readiness, third-party risk, resilience testing.
- EU AI Act / ISO/IEC 42001 — AI system inventory, risk classification, technical documentation, logging and human-oversight controls (see AI & LLM security).
How do we start?
We start with a two-to-three-week security readiness assessment: interviews, architecture and pipeline review, a sample code review, a cloud configuration review and, optionally, a light penetration test. The output is a scored gap report, a prioritised 90-day plan and an estimate for the work — which you can do with your team, with ours, or mixed. The investment is cheap compared with the alternative: IBM lists a DevSecOps approach and employee training among the factors that most reduce the cost of a breach, against an average breach cost of USD 4.88 million (IBM, 2024).
Request a readiness assessment, or check the result from the outside with a penetration test.