A.8.25 Secure development life cycle: evidence and audit

What A.8.25 asks for and why development is where controls break

An assessor or a customer questionnaire asks how your software is built securely, and the answer has to point to rules you have written and can show being applied. A.8.25 Secure development life cycle requires that rules for the secure development of software and systems are established and then applied across the whole life cycle. The control is not satisfied by a policy document alone. The auditor will look for evidence that the rules shaped how code was written, reviewed, tested, released and changed, from the first design decision to decommissioning.

The 2013 edition handled this under A.14.2.1 Secure development policy. The correspondence table in ISO/IEC 27002:2022 Annex B traces A.8.25 back to that control, so organizations that already had a secure development policy under the old numbering can carry it forward, but the 2022 wording expects the rules to be applied, not merely recorded. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.25 to SA-3 System Development Life Cycle, SA-15 Development Process, Standards, and Tools and SA-17 Developer Security and Privacy Architecture and Design, and the NIST Cybersecurity Framework 2.0 mappings tie it to PR.PS-06. NIST cautions that mapped controls are not always equivalent, so treat these relationships as starting points for your own evidence, not as proof that one control satisfies another. Confirm the mapping you rely on against the source documents before you cite it to an assessor.

The requirement is hard because development is where written rules most often fail to reach the systems that matter. A secure coding standard can sit in a wiki while a repository allows direct pushes to the main branch, a pipeline skips the security scan for hotfixes, and a staging environment holds a copy of production customer data. Reconcile your rules against the actual controls: who can merge, which pipeline stages are mandatory, whether production credentials are reachable from build agents, and how exceptions are approved and recorded. Each gap between the written rule and the enforced setting is a finding an assessor is likely to test, and it is cheaper to find it yourself first.

Which systems, repositories and teams fall under A.8.25 in your ISMS

A.8.25 applies to whatever your ISMS scope statement says is developed or changed, so the boundary decisions you make early determine how much work the control creates. The cards below cover the scoping choices that most often change the evidence load, and each one should be checked against the scope statement your certification body will read.

In-house product code

Application repositories your staff write and release are the core of A.8.25. Decide which products, services and repositories sit inside the scope statement, then confirm that each one has a documented development life cycle with security steps in design, coding, review, testing and release. A product left out of scope but sold to customers still tends to draw questions in customer audits, so the scope statement must match what you actually ship. Check branch rules and release records for each in-scope repository.

Infrastructure as code and pipeline definitions

Terraform, Helm charts, Ansible playbooks and CI/CD pipeline files change production behavior as much as application code does. Treat them as in scope when they create or configure production systems, and assign them the same review and approval rules as application code. Ask who can edit pipeline definitions, since a change to a build script can bypass every test that follows it. Record these files in the same repositories or change records so an assessor can trace a production change back to an approved commit.

Third-party and open-source components

Libraries, base images and packages your products depend on are not written by your team, yet they enter your releases. Decide whether your ISMS treats them as inputs to the development life cycle, and document how they are selected, tracked and updated. An inventory such as a software bill of materials lets you show which components reach production and which carry known vulnerabilities or license risk. Confirm with your team which package sources are approved and who accepts a new dependency.

Internal tools that touch production

Deployment scripts, admin consoles, internal dashboards and automation bots often have more production access than customer-facing software, and they are easy to leave out of scope. Include any internal tool that can change production data, configuration or access rights. For each one, confirm who maintains it, how changes are reviewed and whether its activity is logged. Illustrative example: a script that restarts services with administrator rights should be in scope even though no customer uses it directly.

Teams and contractors who write code

A.8.25 follows the work wherever it is done, so scope needs to name the teams that develop, review and release in-scope systems, including contractors working under your processes. Confirm which teams are bound by the secure development rules and which suppliers are covered by contract terms. Work that a supplier builds to your specification is a separate control question, so keep the boundary explicit for each team. Map each team to the scope statement so the boundary is clear to the auditor.

How to implement a secure development life cycle in six steps

This sequence turns A.8.25 from a written policy into a development process that produces evidence in every phase, from the first rules set for developers through the management review that checks whether the process still works. Each step closes with an output an auditor can sample.

Define the secure development policy and phase requirements
The organization owns this step. Security, engineering and product leads write the rules that govern how software and systems are built, covering requirements, design, coding, testing, deployment and maintenance. Each phase gets named security requirements and an owner. Approval by management is recorded. The output is a signed secure development policy and a phase-by-phase requirements document that the auditor will ask to see, along with evidence that developers were told about it.
Separate development, test and production environments
Engineering and platform teams configure distinct environments with separate credentials, network boundaries and access lists, so that code cannot move to production without passing through controlled promotion. Production data is kept out of test environments unless it is handled under the test information rules. The output is an environment diagram, access listings for each environment and a sample promotion record showing who approved the move.
Protect source repositories and enforce review
Repository administrators set branch protection so that protected branches cannot receive direct pushes, merges require approval by a defined role, and force pushes stay disabled unless explicitly allowed. Self-hosted platforms such as GitLab Community Edition provide protected branch settings that can be configured this way. The output is an exported configuration for each critical repository and a sample of merge requests showing that reviews were completed before merge.
Run security checks in every phase
Engineering teams add automated checks to the pipeline: static analysis such as Semgrep Community Edition, dependency and software bill of materials analysis with Trivy or OWASP Dependency-Track, and security testing before acceptance of new releases. Findings are triaged and tracked to closure, and high-risk items block release under a rule written in step one. Teams confirm the checks against their own language and stack, since coverage varies by tool. The output is pipeline configuration, scan reports and records showing findings fixed or formally accepted.
Record developer competence and secure coding training
Engineering managers identify the secure coding and security knowledge each role needs and record completion of training, including training on the organization's own coding standards and the review checklist. Records are kept per person, refreshed when the policy changes and checked when new developers join or change roles. The output is a training matrix, completion records and evidence that the content matches the policy written in step one.
Review the process in management review
The information security lead presents the results of earlier steps to management at planned intervals: policy exceptions, scan trends, open vulnerabilities, outsourced development findings and lessons from incidents. Management decides on corrective actions and assigns owners. The output is the minutes of the review, the list of actions with owners and due dates, and evidence that the actions were tracked to completion. This review feeds the continual improvement cycle required by the management system.

How an assessor tests A.8.25 and what they ask to see

This table compares each area an assessor typically samples for A.8.25, the approach they take, the evidence they ask for and the findings that come up most often. Read it as a pre-audit checklist: if your evidence cannot answer the request in the middle column, expect a finding in the right column. The main takeaway is that an assessor follows the policy into the pipeline, so every written rule needs a matching, recorded control.

Area	Test approach and evidence requested	Common findings
Policy and approval	Review the secure development rules for scope, named owner, approval date and review cycle. Ask who approved them and whether they cover all in-scope development teams and products.	Policy exists but is unapproved, undated or applies only to one team. No evidence the policy was reviewed after major changes.
Security in each phase	Trace a sample of projects through requirements, design, build, test, release and maintenance. Ask for records showing security requirements, threat reviews and sign-offs at each phase.	Phase gates are described in the policy but no completed records exist for sampled releases. Reviews happen informally with nothing written down.
Repository and branch controls	Inspect protected branch settings, required reviews and who can merge or push to production branches. Request configuration exports and a sample of merge records.	Policy requires peer review but branch protection allows direct pushes or self-approval. Force pushes enabled on release branches without a recorded exception.
Automated security checks in pipelines	Compare the written rules against pipeline configuration. Request pipeline definitions, scan results and records of blocked or waived builds.	Policy with no matching pipeline configuration. Scans run but findings are never triaged, or scan jobs are allowed to fail silently.
Environment separation	Confirm development, test and production are separated, with controlled promotion. Ask for access lists per environment and evidence that production data is not used in test without approval.	Developers hold standing production access. Copies of live personal data appear in test environments with no documented approval or deletion record.
Dependency and component management	Ask for software bills of materials for sampled releases and records of how vulnerable or unapproved third-party components were handled.	No inventory of open-source components for shipped products. Known vulnerable components remain in releases without a documented risk decision.
Security testing records	Request test plans, results and remediation tickets for sampled releases, including acceptance testing before release.	Testing is performed but results are not retained. High-severity findings closed without retest evidence or documented acceptance by an authorized person.
Exceptions and deviations	Ask for the register of exceptions to the secure development rules, with approver, reason, compensating measures and expiry.	No record of exceptions even though pipelines show bypasses or waived checks. Exceptions open indefinitely with no review.
Developer competence	Request training records and role-based expectations for secure coding, linked to the people responsible for each phase.	Training is generic and not tied to the languages or frameworks in use. Records do not show who completed what or when.

Which evidence satisfies A.8.25 and how to keep it current

An auditor testing A.8.25 looks for proof that secure development rules exist and were applied throughout the period under review, not only on the day of the audit. The six artifacts below cover the rules, the phase checks, the repository controls, the scan results, the component inventory and the people side, and each one needs a routine that keeps it dated and complete.

Approved secure development rules

This is the written rulebook for building software and systems: the approved languages and frameworks, required design reviews, branching and release rules, and who owns each decision. Auditors check that the document has an owner, a version history and an approval record, and that teams actually follow it. Keep it current by reviewing it on a fixed schedule and after any major change in tooling or product scope. Each revision should record what changed and why, so the period under review shows which rules were in force on each date. Ask the organization to confirm who signs off changes.

Phase requirement checklists

Checklists show that security was part of each stage of the life cycle, from requirements and design through build, test, release and maintenance. A completed checklist attached to a real feature or release is far stronger than a blank template. Auditors sample several recent changes and trace each one back to its checklist. To keep this evidence current, make the checklist a required field in the ticket or pull request template so it is filled in as work happens. Periodically confirm that completed checklists exist for every release in the period.

Repository protection settings exported on a schedule

Protected branch rules show who can push, merge and force push to the code that reaches production. Settings change over time, so a screenshot taken during the audit proves little about the months before it. Export the configuration on a schedule, for example from the platform API, and store the exports with dates. The GitLab documentation on protected branches describes the settings to capture, including blocking direct pushes and keeping force pushes disabled. Compare each export with the rulebook to catch drift early.

Security scan reports with triage decisions

Scan output from static analysis and related tools only counts as evidence when someone reviewed it. Keep each report alongside a record of how every finding was handled: fixed, accepted with a reason and approver, or judged a false positive. Semgrep Community Edition can run in the pipeline and scan repositories continuously, so the reports accumulate automatically. Auditors look for untriaged backlogs and for accepted risks that never expire. Set a recurring review date for accepted findings and confirm the triage log covers the full period.

SBOMs and dependency review records

A software bill of materials lists the components in each release, and dependency review records show how new or changed components were approved. Trivy can generate SBOMs and scan existing ones, and OWASP Dependency-Track ingests CycloneDX SBOMs to flag known vulnerabilities and license risk. Store an SBOM for each released version so the record reflects what shipped at each point in time. Keep approval records for new open-source components with their license IDs. Confirm with the organization which release identifiers link each SBOM to a deployed build.

Training and competence records

Auditors expect developers, reviewers and testers to have the knowledge the rulebook assumes. Training records, role-based secure coding courses and sign-offs for reviewers show that competence was built and maintained. Record each completion with the date, the course content and the person's role, and update the matrix when people join, change roles or leave. Tie refresher training to material changes in the rulebook or tooling. Ask the organization to confirm which roles are in scope and how gaps are escalated.

How open-source tools produce A.8.25 evidence in a self-hosted setup

Open-source tools can generate much of the technical evidence behind A.8.25, but none of them makes an organization compliant on its own. The organization still owns its secure development rules. In a self-hosted setup, GitLab Community Edition (MIT) produces some of the most direct evidence through protected branches. Maintainers can restrict which roles may push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless someone explicitly allows them. Confirm in your own instance that the protected branch settings for production-bound repositories match your documented change rules, and export or screenshot those settings with dates so an assessor can see the configuration that applied during the audit period. Confirm too that the same rules apply to administrators, since a setting that only restricts ordinary developers gives weaker evidence.

Semgrep Community Edition (LGPL-2.1-only) provides static analysis that can run inside CI/CD pipelines and scan repositories on every change. Its supported languages include C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, and you can apply community rules or write custom rules for your own coding standards. Check the supported-language list against the languages your teams actually use before you rely on it, and record which rule sets run in which pipelines. Pipeline logs showing scan results and blocking behavior are the evidence most useful for the secure coding and security testing expectations that sit beside A.8.25. OWASP Dependency-Track (Apache-2.0) covers the component side. It consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component through SPDX license IDs. Confirm how your team triages its findings and keeps VEX decisions with dated justifications.

Trivy (Apache-2.0) completes the chain by identifying OS packages and software dependencies in a target and producing them as a software bill of materials. It can also scan existing SBOMs, which lets you feed components produced elsewhere into the same review. A practical check is to generate an SBOM for each release artifact, load it into Dependency-Track, and confirm that the component list matches what was built. Before you describe this setup to an auditor, confirm each capability in your own environment, including the versions you run, the licenses that apply to your deployment, and whether your retention of scan outputs meets your own evidence rules. Treat the outputs as records of how your secure development rules were applied, not as proof that the rules exist or are followed.

What meeting A.8.25 costs in money and effort

This table breaks down the cost components of meeting A.8.25 Secure development life cycle, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are given because none are supplied; use the quote checklist to compare written scopes. Self-hosted open-source tooling mainly removes license spend, not engineering or evidence effort.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Tooling and licenses (repository, scanners, SBOM tools)	Recurring if commercial; near zero license cost for self-hosted open source	Number of repositories, pipelines and users; commercial add-ons for support or advanced rules	Self-host GitLab Community Edition, Semgrep Community Edition, Dependency-Track and Trivy; confirm feature gaps against your needs before committing
Infrastructure to host development tools and separated environments	Recurring	Number of separated development, test and production environments; high availability and backup requirements	Reuse existing cloud accounts or data centers; size environments to actual workloads and document them as code
Engineering time to configure pipelines and protections	One-time, with ongoing tuning	Number of protected branches, required reviews, scanner rules and SBOM generation steps; legacy repositories needing rework	Standardize pipeline templates across repositories and apply branch protection as code; ask the partner to deliver reusable configuration
Policy, standards and secure coding guidance	One-time, with periodic review	Number of development teams, languages and product lines covered; alignment with existing policies	Start from one secure development policy and extend it; reference existing coding standards rather than writing new ones
Developer training and competence records	Recurring	Team size, staff turnover and role-specific training needs	Use role-based training tied to the scanner findings the team actually sees; keep attendance records in the same system as other evidence
Evidence upkeep (pipeline logs, review records, SBOMs, scan results)	Recurring	Release frequency, number of products and retention periods set by policy	Automate evidence export from the pipeline and store it in a retained location; avoid manual screenshots
External security testing or code review	Recurring or per engagement	Application count, architecture complexity, testing depth and retest cycles	Scope testing to high-risk applications first; agree scope and deliverables in writing before work starts
Auditor sampling and assessment time	Recurring at each surveillance or recertification audit	Number of products, releases and developers the auditor samples; quality of evidence at the start	Ask the certification body how it samples; keep one traceable record per release from requirement to test result

Who owns secure development rules and who prepares the evidence

Your organization owns the secure development rules. Under A.8.25 the rules must be established and then applied, and that means someone with authority has to decide what the rules say, approve exceptions, and accept or reject releases. Those decisions cannot be delegated to a vendor, because the auditor will ask who in your organization accepted the risk of each release and on what basis.

Policy and scope: Your team writes and approves the secure development policy, defines which systems and repositories it covers, and assigns an owner who answers for it.
Developer behavior: Engineering leads set expectations for branch rules, code review, dependency updates and handling of security findings, and enforce them in daily work.
Acceptance decisions: Someone accountable signs off on security testing results before production release, including any accepted findings and their expiry dates.
Competence: Your team decides which developers need secure coding training and keeps records that the training happened.
Management review: Leadership reviews the policy and exception records at planned intervals so the rules stay current.

Before relying on any partner, confirm that your own policy owner can explain each rule and point to the record that shows it was applied.

Where secure development programs usually fall short at audit

Auditors testing A.8.25 rarely fail a program for lacking a policy document. They find that the written rules are not enforced by the tools, repositories and records that developers use every day. The six gaps below connect policy to pipeline, data handling, findings triage and competence, and each lists the evidence that shows the gap is closed.

Policy no pipeline enforces

A secure development policy that exists only as a PDF gives an assessor nothing to test. Check whether the required steps, such as code review, security scanning and dependency checks, run automatically in the build pipeline and block a merge when they fail. Map each policy clause to a named pipeline job or a documented manual gate with an owner. Evidence: pipeline configuration files under version control, recent failed-pipeline records, and the policy mapped to those jobs.

Unprotected main branches

If any developer can push directly to the main branch or force-push history, changes reach production without review, and the audit trail is unreliable. Confirm that protected branches restrict who can push or merge, that direct pushes are blocked for the default branch, and that force pushes stay disabled. Evidence: branch protection settings exported from the repository, and a sample of merged changes showing an approving reviewer.

Production data in test environments

Teams often copy live customer records into staging to reproduce bugs, which moves personal and confidential data into a less controlled environment. Require that test data be synthetic or masked, that production data copies need documented approval, and that they are deleted after use. Separate environments with their own access controls. Evidence: test data procedure, approval records for any production extract, and deletion logs or tickets.

Scanner findings without triage

Static analysis and software composition tools generate findings continuously, and an assessor will ask what happened to each one. Without a triage record, a finding is either silently ignored or fixed without trace. Define severity levels, owners, target fix windows and a documented route for accepted risk. Track component vulnerabilities and license issues in one place so that decisions can be reviewed. Evidence: the findings register with status, owner and decision for each item, and records of accepted risks with approval.

Open-source components without inventory

Applications pull in libraries and container base images that nobody has listed, so when a vulnerability is published the team cannot say which products are affected. Generate a software bill of materials for each build, store it with the release, and scan it against current vulnerability data. Confirm that the sources of open-source components are approved. Evidence: SBOMs in a standard format attached to each release, and a record of which components were approved for use.

Developers with no recorded competence

A policy assumes developers know secure coding, yet many programs cannot show who was trained, on what, or when. Set a secure coding curriculum matched to the languages and frameworks each team uses, and track completion and refresher training. Link competence to role so that new hires and contractors are covered. Evidence: training plans by role, completion records with dates, and assessment results for hands-on exercises.

Common questions about A.8.25 cost, effort and audit evidence

How much effort does A.8.25 take for a small team?

No researched figure is available for the effort A.8.25 takes, and the amount depends mostly on how much software your team builds, how many repositories and environments exist, and whether development already follows documented phases. A small team with one product, one repository and a single release path usually needs a written secure development rule set, a short list of security checks per phase and recorded evidence that those checks ran. Ask any partner to break the effort into policy writing, tooling setup, process changes, developer training and evidence collection, and to state which parts recur each release cycle. Confirm the scope against your own repositories before accepting any estimate.

Can open-source tools produce the evidence A.8.25 needs?

Open-source tools can produce much of the technical evidence, but they do not write the rules or decide what counts as acceptable. GitLab Community Edition supports protected branches that restrict who can push or merge and can block direct pushes, which gives you records of who changed protected code. Semgrep Community Edition can run in CI/CD pipelines with community or custom rules across many languages, producing scan results per change. OWASP Dependency-Track and Trivy help track components through CycloneDX SBOMs and known vulnerabilities. Confirm that each tool covers your languages and retains the records an assessor will ask for, because the auditor tests whether the process runs consistently, not whether a tool is installed.

How long does preparation usually take, and what drives it?

No researched duration is available for A.8.25 preparation, so treat any timeline you receive as an estimate to be tested. The main drivers are the number of products and repositories in scope, how mature your current release process is, whether environments are already separated, how many third-party or outsourced developers contribute code, and how quickly your team adopts new scanning and review steps. Ask for milestones tied to specific deliverables, such as a written rule set, a configured pipeline, a tested rollback and a first cycle of evidence. Shorter timelines usually reflect fewer products and an existing change process, not a shortcut through the requirement.

What does the internal team need to supply?

The organization owns the control, so internal people must make the decisions and keep the work running. Typically this includes an accountable owner for the secure development rules, engineering leads who approve how each phase is secured, repository and CI/CD administrators, and a person who reviews scan results and tracks exceptions. Developers need competence in the secure coding practices your rules require, and someone must keep records of training. An implementation partner can draft and configure these, but ongoing approvals, risk acceptances and reviews must come from your staff. Ask the partner to list every internal role and hours they expect each role to spend.

Can our internal team implement A.8.25 alone?

Yes, a capable internal team can implement A.8.25 without outside help, provided it has engineering time, security expertise for the rules and someone accountable for evidence. The harder parts are usually writing rules that fit real release practice, configuring repository protections and pipeline scans consistently, and collecting evidence across every product. External help is most useful when the team lacks security engineering capacity or needs an independent view of its design. Whichever route you take, the certification body issues any certificate, and it does not accept preparation work as a substitute for an independent audit.

How should the NIST and NIS2 crosswalk mappings be read?

Treat the mappings as starting points for analysis, not as proof that one control satisfies another requirement. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.25 to SA-3, SA-15 and SA-17, and NIST warns that mapped controls are not always equivalent. ENISA's mapping for NIS2 technical guidance links A.8.25 to point 6.2 of the annex to Implementing Regulation (EU) 2024/2690. The CSF 2.0 mappings from non-NIST submitters relate A.8.25 to PR.PS-06, which NIST does not endorse. Check each mapped requirement against its actual wording and your own evidence, and ask your assessor how they treat cross-framework reuse.

What should we ask a partner for in a quote?

Ask for a written scope that lists the products, repositories, environments and teams covered, plus the deliverables and dates agreed before work starts. A useful quote separates one-time work, such as the rule set, pipeline configuration and training, from recurring work, such as scan review, upgrades and evidence collection. It should name the tools, state who operates them, and explain what the client must provide. Confirm that the partner prepares evidence but does not issue audit reports or certificates, and ask how the handover of records and runbooks will work. DeployOpen provides fixed-scope engagements agreed in writing, and the quote follows from that written scope.

How DeployOpen scopes and prepares A.8.25 evidence

DeployOpen works on A.8.25 Secure development life cycle as an implementation partner. We prepare the development environments, repositories, pipeline checks and records that show how rules for secure development are established and applied. Your organization owns the rules and the controls, and an independent auditor or certification body decides whether the evidence meets the standard.

How we scope

Engagements are fixed-scope, with the systems, repositories and pipelines covered agreed in writing before work starts.
The written scope lists which development, test and production environments the A.8.25 rules must reach.
Scope also records who owns each secure development rule, so responsibilities stay with your organization.

How we build

We configure protected branches and review rules in self-hosted GitLab so unreviewed code cannot reach release branches.
We wire Semgrep scans into CI/CD pipelines so repositories are checked continuously against agreed rules.
We set up Dependency-Track and Trivy to produce and track software bills of materials for each application.

How we hand over

You receive documentation of the secure development rules, the pipeline configuration and the owners of each check.
Evidence packs list pipeline logs, branch settings, scan results and SBOM records mapped to the agreed scope.
We train your developers and reviewers on the tooling so the checks keep running after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can keep scanning rules, SBOM tracking and pipeline settings current as your code and dependencies change.
Confirm with your auditor which evidence formats and sampling they expect before the scope is finalized.