ISO/IEC 27001:2022·Annex A A.8.25·high·Component: Technological controls

What this control requires

Rules for the secure development of software and systems shall be established and applied.
— ISO/IEC 27001:2022, Annex A A.8.25

In plain English

Rules for the secure development of software and systems shall be established and applied. In practice, this means you can prove you policy management-level controls on a defined cadence.

Why it matters

ISO 27001 certification depends on showing each Annex A control is either implemented or explicitly justified for exclusion in the Statement of Applicability (SoA). Certification bodies sample controls during surveillance audits, and a missing SoA entry — or implementation that doesn't match the SoA wording — is a finding.

This control is rated high. Auditors expect a named owner, a remediation SLA, and a tooling artefact that evidences continuous operation.

What an auditor looks for

An ISO 27001 lead auditor looks for: (1) an SoA entry covering the control with justification, (2) a documented procedure or policy implementing it, (3) records that prove the procedure runs (logs, tickets, training records) and (4) management-review evidence that effectiveness is monitored.

Within Technological controls, the assessor will trace your implementation back to the catalogue reference (Annex A A.8.25) and look for objective evidence on the latest two assessment cycles.

How to implement

Policy Management

Docs. Keep each policy in version-controlled Markdown alongside the code that implements it; ship a signed PDF snapshot at each annual review and link the SHA into the SoA.

Secure Development

Pipeline. Require code review, SAST (Semgrep / Snyk Code), SCA (Dependabot / Renovate), secret-scanning and IaC scanning in the merge pipeline.

Branch protection. Protected branches enforce reviews, signed commits and passing CI before merge; document the protection rules as the control evidence.

Operational checklist

  • Policy. Document the trigger, the owner and the cadence.
  • Management. Document the trigger, the owner and the cadence.
  • Secure. Document the trigger, the owner and the cadence.
  • Scope: management, software, development life cycle.

Evidence to collect

  • Code Repo Scan. Source-control evidence — branch protection, required reviewers, CI status, SCA / SAST reports.
  • Ticketing Workflow. ticketing_workflow evidence

CI/CD guardrails (GitHub Actions, GitLab) and change workflows enforce secure SDLC checkpoints.

Common pitfalls

  • Policies that no engineer has read; the version in Confluence drifts from the version that's actually being enforced.
  • CI security checks set to warn-only; the merge button is faster than the security feedback.

How it maps to other frameworks

Computed from shared tags, control component and key-operation subjects — handy when you are reconciling controls across an audit.

Related controls in ISO/IEC 27001:2022

References

Topics: governance riskpolicy managementsecure development