ISO 27001 DevSecOps: mapping secure development controls to your pipeline

ISO 27001 certifies the information security management system around how your company governs information risk. For a software team, the practical question is narrower: can your delivery process show evidence that secure development controls operate during design, coding, review, release, and remediation?

That is where DevSecOps matters. It turns ISO 27001 secure development expectations into CI/CD controls, pull request records, vulnerability tickets, access reviews, deployment logs, and exception approvals. The audit value is not the scanner output alone. The audit value is the documented chain from risk to control, from control to owner, and from finding to remediation.

TL;DR

• ISO 27001 DevSecOps means mapping secure development controls into your pipeline so engineering can produce audit-ready evidence without stopping delivery.
• For Dutch and EU SaaS teams, the useful evidence usually includes pull request reviews, SAST and SCA results, access review records, exception approvals, deployment logs, and remediation tickets with owners and dates.
• Use this approach when your team is preparing for ISO 27001 certification, recertification, customer security questionnaires, or internal audit. Watch for one common failure: treating scan results as proof of compliance without showing who reviewed the finding, what was fixed, and when the control was rechecked.

What does ISO 27001 require from software delivery?

ISO 27001 requires a managed security system, not a one-time security report. In software delivery, that means your ISMS needs to show how security risks are identified, treated, assigned, reviewed, and improved across the delivery lifecycle.

ISO/IEC 27001:2022 is an information security management system standard. It asks the organisation to define security objectives, assess risks, choose controls, document responsibilities, and improve the system over time. ISO/IEC 27002:2022 supports that work by giving implementation guidance for controls.

For engineering teams, the relevant control areas usually sit around secure development, access control, change management, vulnerability handling, logging, monitoring, and supplier or outsourced development. The exact scope depends on your Statement of Applicability, your risk assessment, and what your auditor expects to see.

The most practical way to translate this into software delivery is to separate three layers.

• First, the ISMS layer defines policy and accountability. This includes risk assessment, the Statement of Applicability, secure development policy, access policy, change policy, and supplier security requirements.
• Second, the delivery layer shows how those policies run inside engineering. This includes pull request review rules, branch protection, CI/CD gates, dependency checks, deployment approvals, and vulnerability triage.
• Third, the evidence layer proves that the controls operated. This includes review logs, ticket histories, scan reports, access review sign-offs, exception records, and release notes.

If your team still needs the certification journey before the delivery mapping, use the ISO 27001 certification process guide first, then return to this guide to convert secure development controls into engineering evidence.

ISO 27001 evidence should answer four audit questions:

Audit question	Engineering translation	Evidence to keep
What control applies?	Which secure development or pipeline control maps to this risk?	Statement of Applicability, control mapping, secure development policy
Who owns it?	Which role reviews, approves, fixes, or accepts risk?	RACI, ticket owner, approval record
How often does it run?	Per pull request, per release, weekly, monthly, or quarterly?	CI/CD logs, review records, access review calendar
What changed after review?	Was the risk fixed, accepted, deferred, or escalated?	Remediation ticket, exception approval, retest evidence

The control is only audit-ready when all four questions have a documented answer.

How to map ISO 27001 controls to a DevSecOps pipeline

Map ISO controls to DevSecOps by assigning each control area to one pipeline stage, one evidence artifact, one owner, and one review frequency. A control without an owner becomes a policy statement. A control with a recurring evidence trail becomes auditable.

For a Dutch or EU SaaS company, the useful mapping usually starts with secure development controls under ISO/IEC 27001:2022 Annex A, then connects them to engineering workflows.

ISO 27001 control area	Pipeline control	Evidence artifact	Owner	Frequency
Secure development lifecycle	Security requirements added before development starts	Security acceptance criteria, threat notes, architecture decision record	Product owner, Security Lead, Engineering Manager	Per feature or epic
Application security requirements	Security requirements included in backlog and test cases	User story security criteria, QA test record	Product owner, QA Lead	Per sprint
Secure system architecture and engineering principles	Architecture review before high-risk changes	Architecture decision record, review comments, risk notes	Tech Lead, Security Lead	Per major change
Secure coding	Peer review, branch protection, coding standards	Pull request review, merge approval, branch rule config	Engineering Manager, Tech Lead	Per pull request
Security testing in development and acceptance	SAST, SCA, DAST, secret scanning, manual review where needed	Scan reports, triage notes, retest results	DevSecOps Engineer, QA Lead	Per build or release
Management of technical vulnerabilities	Severity-based triage and remediation SLA	Vulnerability tickets, fix dates, risk acceptance records	Security Lead, Engineering Manager	Weekly or per release
Access control and access rights	Least-privilege access for code, cloud, CI/CD, and production	Access matrix, approval tickets, quarterly review sign-off	IT Admin, Security Lead	Quarterly
Change management	Release approval and rollback procedure	Deployment log, change ticket, release approval	Release Manager, Engineering Manager	Per release
Logging and monitoring	Security events logged for build, deploy, and production systems	Log retention policy, monitoring alerts, incident ticket	DevOps Lead, Security Lead	Continuous, reviewed monthly
Outsourced development	Supplier controls for external engineering support	DPA, access scope, onboarding record, offboarding record	Compliance Manager, Vendor Owner	Per vendor and quarterly

The mapping should not be a static spreadsheet that gets updated before audit week. It should be tied to existing work systems: Jira, Azure DevOps, GitHub, GitLab, Bitbucket, cloud IAM, CI/CD tooling, and vulnerability management tools.

For example, secure coding evidence should come from pull requests and merge rules. Vulnerability evidence should come from tickets and retest records. Access control evidence should come from access reviews and approval logs. Change management evidence should come from deployment records and release approvals.

This is also where ISO 27001 DevSecOps differs from a general DevSecOps pipeline guide, explaining where security belongs in CI/CD. This article answers a narrower question: what evidence does that pipeline need to produce for ISO 27001?

A practical mapping rule works well here: if the control cannot produce evidence without a manual scramble, it is not yet embedded in delivery.

Which evidence should engineering keep for an audit?

Engineering should keep evidence that shows the full control cycle: requirement, review, finding, decision, fix, and recheck. A scanner report by itself only shows detection. ISO 27001 evidence needs to show governance and follow-through.

The most useful audit evidence is produced during normal delivery work. Do not wait until audit preparation to create it. Build the evidence trail into the workflow.

Pull request and code review evidence

Keep pull request records that show who reviewed the change, what was discussed, which security checks passed, and who approved the merge. A useful pull request record includes:

Evidence field	What it proves
Reviewer name and timestamp	The review happened before merge
Required reviewer rule	Peer review is enforced, not optional
Security-related comments	The team looked for security impact, not only functionality
Linked ticket or story	The change connects to approved work
CI/CD status checks	Automated checks passed before merge

SAST, SCA, secret scanning, and DAST evidence

Keep scan results, but connect them to triage and remediation. The evidence should show which findings were accepted, fixed, or deferred. A finding without triage is noise. A finding with owner, severity, due date, fix commit, and retest record becomes audit evidence. Use severity thresholds before the audit begins. For example:

Severity	Suggested delivery rule
Critical	Block release unless a documented risk acceptance exists
High	Fix before release or within the agreed sprint SLA
Medium	Add to remediation backlog with owner and target date
Low	Track, batch, or accept based on risk context

The exact thresholds should match your risk appetite, customer commitments, and auditor expectations. The key is consistency. If one release blocks on a high-severity dependency issue and another release ignores the same issue without approval, the evidence trail becomes weak.

Exception and risk acceptance records

Not every finding blocks a release. Some risks are accepted temporarily because a compensating control exists, the affected component is not internet-facing, or a business deadline has been approved by the right owner. The exception record should state:

Field	Required detail
Finding	What risk exists
Reason	Why the release can continue
Compensating control	What reduces exposure
Owner	Who accepts the risk
Expiry date	When the exception must be reviewed
Follow-up ticket	What will close the risk

Without an expiry date, an exception becomes a permanent blind spot.

Access review evidence

Access reviews matter because DevSecOps tooling often touches source code, secrets, build systems, production logs, and cloud infrastructure. Keep records for code repositories, CI/CD platforms, cloud accounts, production systems, monitoring tools, and vulnerability platforms.

A quarterly access review is a practical cadence for many SaaS teams. The review should show who has access, what changed since the previous review, who approved continued access, and which accounts were removed.

For Dutch and EU SaaS teams working with external engineers, access evidence should also show onboarding and offboarding. The audit question is simple: did each person have the right access, for the right period, with documented approval?

Deployment and change records

Deployment logs should show what changed, who approved the release, which checks passed, and how the team could roll back if needed.

A release record should connect:

Release element	Evidence
Change request	Ticket or release scope
Approval	Product, engineering, or change owner sign-off
Security gate	CI/CD results, scan threshold, exception record
Deployment	Timestamp, environment, version, actor
Rollback	Rollback plan or previous version reference

If the release changes authentication, payment, customer data handling, encryption, or administrative access, add a security review before deployment.

Example audit-evidence folder structure

The practical structure can be simple as long as every folder maps to a control area and owner.

Example:

ISO-27001-DevSecOps-Evidence/
  01-secure-development-policy/
  02-control-mapping-and-SoA/
  03-architecture-and-threat-review/
  04-code-review-records/
  05-ci-cd-security-gates/
  06-vulnerability-management/
  07-risk-acceptance-and-exceptions/
  08-access-reviews/
  09-release-and-change-records/
  10-supplier-and-outsourced-development/
  11-audit-testing-and-follow-up/

The folder structure is not the control. It is the index that helps your team find the control evidence when an auditor, buyer, or internal reviewer asks for it.

If your team builds mobile or customer-facing applications, the related ISO 27001 and app development article can support the app-specific angle while this article stays focused on DevSecOps pipeline evidence.

How to avoid slowing delivery while collecting evidence

The fastest way to collect ISO 27001 evidence is to stop collecting it manually. Evidence should be created by the same systems that already manage code, builds, releases, access, and tickets.

A SaaS team should not add a manual compliance step to every sprint if the CI/CD platform, ticketing system, and repository already contain the proof. The work is to standardise naming, ownership, thresholds, and storage.

Use policy-as-code for repeatable controls

Policy-as-code turns control rules into repeatable checks. Examples include branch protection, required reviewers, required status checks, dependency thresholds, infrastructure policy checks, and secret scanning.

The advantage is consistency. A manually reviewed checklist depends on who is working that day. A pipeline rule applies the same gate every time. Use policy-as-code where the rule is clear:

Control need	Good automation fit
Required code review	Branch protection
Dependency severity threshold	SCA gate
Secret detection	Secret scanning
Infrastructure policy	IaC scanning
Deployment approval	Protected environments
Access expiry	IAM workflow or access management tool

Keep human review for decisions that require context: risk acceptance, architecture trade-offs, compensating controls, and customer impact.

Define release gates by severity and system risk

A release gate should block the few risks that matter most. If every scan finding blocks release, teams will work around the control. If nothing blocks release, the control has no force.

A practical starting point:

Situation	Release decision
Critical vulnerability in internet-facing service	Block release unless approved risk acceptance exists
High vulnerability in dependency with available fix	Fix before release or document approved exception
Medium finding in internal tool	Track in backlog with owner and target date
Low informational finding	Batch review monthly
Secret detected in repository	Block and rotate credential before release
Missing reviewer on protected branch	Block merge

Release gates should be reviewed after one or two release cycles. If gates block too much low-risk work, adjust thresholds. If gates allow repeated high-risk exceptions, fix ownership.

Keep evidence close to the work

Evidence should live near the system of record. Pull request evidence belongs in the code platform. Vulnerability evidence belongs in the ticketing and scanning tools. Access evidence belongs in IAM or access review records. Release evidence belongs in deployment logs and change tickets.

The evidence folder should link to those systems rather than duplicate everything manually. Duplicated evidence creates drift. Linked evidence keeps the audit trail closer to the actual work.

For teams also preparing for Dutch NIS2 requirements, some evidence can support both ISO 27001 and NIS2 readiness. The overlap is not automatic, but the same engineering records often help answer security management, incident handling, access control, and vulnerability management questions. For the Dutch regulatory angle, see DevSecOps and NIS2 for Dutch companies.

Common ISO 27001 DevSecOps mistakes

The most common ISO 27001 DevSecOps mistake is confusing activity with evidence. Running scans, holding reviews, or using DevSecOps tools does not help an audit unless the output is documented, owned, reviewed, and connected to risk treatment.

Mistake 1: Treating scanner output as compliance proof

SAST or SCA results can support ISO 27001 evidence, but they do not prove compliance alone.

The missing part is the decision trail. Who reviewed the finding? Was it exploitable? Was it fixed, accepted, or deferred? What retest evidence shows closure?

A useful scan record should connect to a ticket, owner, severity, decision, target date, fix commit, and retest result.

Mistake 2: Keeping evidence across scattered tools with no index

Engineering evidence often exists, but nobody can find it quickly. Pull requests are in GitHub, issues are in Jira, approvals are in Slack, access records are in Google Workspace, and deployment logs are in the cloud console.

That setup fails when audit preparation becomes a search exercise.

Create one evidence index with links to the systems of record. The index should show control area, owner, evidence location, review frequency, and last review date.

Mistake 3: Assigning controls to tools instead of people

Tools do not own controls. People do.

A SAST tool can detect a vulnerability. It cannot decide whether the finding blocks release. A CI/CD gate can enforce a threshold. It cannot approve a risk exception. An access management tool can show user rights. It cannot explain why a contractor still has production access six weeks after project end.

Every control needs an accountable role: Security Lead, Engineering Manager, Tech Lead, Release Manager, Product Owner, IT Admin, or Compliance Manager.

Mistake 4: Using the 2013 control language without mapping to 2022

Many older articles and templates still refer to ISO 27001:2013 Annex A.14 for system acquisition, development, and maintenance. For new work, map your language to ISO/IEC 27001:2022 Annex A controls and your Statement of Applicability.

If legacy documents still use A.14, keep a mapping note. Do not let old control labels create confusion in audit evidence, internal training, or customer questionnaires.

Mistake 5: Writing risk acceptance with no expiry date

Risk acceptance without an expiry date becomes unmanaged risk.

Each exception should have an owner, reason, compensating control, expiry date, and follow-up ticket. Review exceptions before the next release or at the agreed cadence. Expired exceptions should be escalated, closed, or renewed with documented approval.

Mistake 6: Making compliance a separate lane from engineering

If compliance evidence sits outside delivery, it becomes late, incomplete, and expensive to maintain. The better pattern is to make the delivery system produce evidence by default.

That means repository rules, CI/CD gates, ticket workflows, access review calendars, and release approvals need to align with the control map. The audit trail should be the byproduct of controlled delivery, not a reporting project at the end of the quarter.

How Sunbytes supports ISO 27001 DevSecOps delivery

Sunbytes supports ISO-aware DevSecOps delivery by helping SaaS teams turn secure development controls into working delivery practices, evidence trails, and remediation ownership. The goal is not to claim that a client product becomes ISO certified because Sunbytes is certified. The goal is to help the client build the evidence their own ISMS, audit, or customer review requires.

Sunbytes is ISO 27001 certified and works with delivery models where security controls need to operate inside real engineering work: code review, CI/CD, vulnerability handling, release approval, access review, and audit documentation.

For Dutch and EU SaaS teams, the practical support usually falls into three areas.

• First, Sunbytes helps define the control-to-delivery map. That means connecting secure development expectations to the pipeline stage, evidence type, owner, and review cadence.
• Second, Sunbytes helps close delivery gaps. If the team lacks DevSecOps capacity, security review ownership, or remediation bandwidth, Sunbytes can add engineering support without restarting the hiring cycle.
• Third, Sunbytes helps prepare audit-ready evidence. That includes control mapping, remediation records, access review support, DPA-backed delivery, and evidence trails that security questionnaires and auditors can inspect.

The output should be concrete: a mapped control set, evidence locations, named owners, remediation actions, and a next-step plan for gaps that cannot be solved in the current sprint.

Let’s start with Sunbytes

Let us know your requirements for the team and we will contact you right away.

Name(Required)

First Last

Company(Required)

Email(Required)

How can we help you(Required)

How can we help you?Custom Software developmentDedicated Tech servicesHR services (Vietnam)Cybersecurity servicesOthers

How did you hear about us?(Required)

How did you hear about us?LinkedInClutchNewsletterSearch engine (Google, Bing, Yahoo,…)EmailReferralOthers

Message

untitled(Required)

I allow Sunbytes to contact me via email and phone

Untitled(Required)

I agree to the general terms & conditions

Captcha

Name

This field is for validation purposes and should be left unchanged.

Δ