BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 19, 2026

Quick answer: DevSecOps compliance is the point where secure development stops being good engineering and becomes audit evidence. Compliance frameworks that cover organizations building software, including SOC 2, ISO 27001, PCI DSS, and HIPAA, require documented secure development practices, not just deployed infrastructure controls. All of them include requirements for secure software development, change management, and vulnerability management in the application layer that cannot be satisfied by network controls, EDR, or access management alone. A working DevSecOps program, with documented SDLC processes, configured CI/CD security gates, and metrics that demonstrate the controls are operating, is the set of artifacts that satisfies these requirements. Organizations that build software and operate under compliance obligations but have no documented secure SDLC will consistently have findings in this control domain regardless of how well-controlled the rest of their environment is.

Key Takeaways

• Compliance frameworks distinguish between the security of the infrastructure and the security of the software running on it. Network segmentation, EDR, and identity controls address infrastructure security. Secure SDLC controls, application security testing, and change management address application security. Both layers are required. An organization with excellent infrastructure security but no secure development practices satisfies the infrastructure controls and fails the application security controls, which is a consistent and predictable audit gap for software-building organizations.
• Auditors do not accept a statement that secure coding practices are followed. They ask for evidence: documented processes, tool configurations, finding records, and metrics that demonstrate the controls are operating over the audit period. A DevSecOps program that produces CI/CD security gate configurations, SDLC process documentation, a findings history with remediation records, and a security metrics dashboard is producing the evidence record the auditor needs. A development team that follows good practices informally but has no documentation produces nothing auditors can evaluate.
• PCI DSS has the most explicit and prescriptive secure development requirements of the major compliance frameworks. Version 4.0 Requirement 6 covers development and maintenance of secure systems and software with specific requirements for secure coding practices, code reviews, vulnerability testing of internally developed applications, and the use of web application firewalls. Organizations in the PCI DSS scope that build payment-related software need a documented secure SDLC that satisfies these requirements explicitly.
• SOC 2 Type II, the most common certification for SaaS and technology companies, covers the operating effectiveness of controls over the audit period, typically six to twelve months. A DevSecOps program that is implemented and then not maintained does not satisfy SOC 2 Type II requirements because the Type II assessment evaluates whether controls were operating continuously, not just whether they were in place at a point in time. The security metrics dashboard produced by a DevSecOps engagement provides the operating effectiveness evidence the Type II assessment requires.
• The NIST SP 800-218 Secure Software Development Framework is increasingly referenced as the benchmark for secure development practice in US federal procurement and in private sector compliance assessments. It is organized around four groups that map directly to the components of a DevSecOps program: prepare the organization (governance and training), protect the software (security in design and development), produce well-secured software (security testing), and respond to vulnerabilities (ongoing vulnerability management).

Framework by Framework: What DevSecOps Addresses

The distinction that runs through every framework is the one in the first takeaway: infrastructure security and application security are separate control domains, and both are assessed. The endpoint and network side is covered by controls like the ones in EDR compliance and endpoint protection; the application side is where secure SDLC compliance lives. If you want the ground-level view of what a DevSecOps program actually is before mapping it to controls, what DevSecOps means for a business covers that first.

SOC 2

SOC 2 Trust Services Criteria CC8.1 requires that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. This criterion covers the entire change management process for software, from design through testing and approval to deployment. A CI/CD pipeline with configured security gates, a documented code review process with security checklist, and SAST and SCA running on every pull request provide the testing and approval components. The documented secure SDLC process satisfies the documentation component. The deployment pipeline with defined promotion gates satisfies the controlled deployment component.

CC7.1 requires the entity to use detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities, and CC6.1 requires the entity to implement logical access security controls over its protected information assets. Application security testing, particularly DAST that tests the running application from an external perspective, contributes to the CC7.1 evidence record by demonstrating that the application’s attack surface is evaluated and known vulnerabilities are identified and managed. For SaaS companies, where the application is the primary system component in scope for SOC 2, the application security controls are often the most scrutinized part of the assessment.

ISO 27001

ISO 27001:2022 Annex A A.8.25 requires a secure development life cycle with rules for the secure development of software and systems established and applied. A.8.26 requires application security requirements, with information security requirements identified, specified, and approved when developing or acquiring applications. A.8.28 requires secure coding practices, with secure coding principles applied to software development. A.8.29 requires security testing in development and acceptance, with security testing processes defined and implemented in the development life cycle. A.8.31 requires separation of development, test, and production environments.

These five controls together define a comprehensive secure software development requirement for ISO 27001 that maps directly to DevSecOps program components: SAST and DAST for security testing (A.8.29), secure coding standards and training for secure coding practices (A.8.28), documented application security requirements for the development lifecycle (A.8.26), the SDLC process documentation for the secure development lifecycle (A.8.25), and environment separation enforced through the CI/CD pipeline (A.8.31). A DevSecOps engagement that produces documented processes and working tool configurations creates the evidence base for all five controls.

PCI DSS

PCI DSS v4.0 Requirement 6 is the most detailed set of secure development requirements in any major compliance framework, which makes DevSecOps and PCI DSS tightly coupled for any organization that builds its own payment-related software. Requirement 6.2 requires that bespoke and custom software are developed securely, with processes defined for software development that follow established industry standards. 6.2.2 requires that all personnel involved in bespoke software development receive training on secure coding at least annually. 6.2.3 requires review of bespoke and custom software prior to release to production to identify and correct potential vulnerabilities using either automated application vulnerability security testing tools or manual code review. 6.2.4 requires that software engineering techniques or other methods are defined and in use to prevent or mitigate common software attacks and related vulnerabilities in bespoke software.

For organizations in PCI DSS scope that build their own software, these requirements make a documented DevSecOps program essentially mandatory. The SAST tool configurations and findings records satisfy 6.2.3. The developer training program and records satisfy 6.2.2. The secure coding standards, including concrete practices like keeping credentials out of source code, and OWASP Top 10 coverage satisfy 6.2.4. The documented SDLC process satisfies 6.2.1. PCI DSS v4.0 Requirement 6.3 additionally requires identification and management of vulnerabilities in third-party software components, which is what SCA provides. The compliance mapping that Armour Cybersecurity produces as part of the DevSecOps engagement maps each program component to its specific PCI DSS requirement, making the audit evidence straightforward to present.

HIPAA

HIPAA’s Security Rule does not prescribe specific software development practices as explicitly as PCI DSS, but its technical safeguard requirements for access control, audit controls, integrity, and transmission security apply to the applications that process or transmit electronic protected health information (ePHI). Applications built without secure development practices may have vulnerabilities that bypass or undermine these technical safeguards: an injection vulnerability that allows unauthorized access to ePHI bypasses access controls; an application that stores ePHI without proper encryption fails the integrity and transmission security requirements.

HIPAA compliance for software-building organizations requires that the applications handling ePHI are developed with security requirements built in, tested before deployment, and maintained with known vulnerabilities addressed. The HHS Office for Civil Rights, in its audit protocols, evaluates whether covered entities have implemented appropriate technical safeguards across their information systems, and applications that process ePHI are information systems subject to that evaluation. A documented secure SDLC with evidence of security testing for applications that handle ePHI satisfies the HIPAA requirement for appropriate technical safeguards in software.

What Auditors Actually Look For

Across all of these frameworks, auditors are looking for three things: documented processes that describe how secure development is practiced, evidence that the processes were followed during the audit period, and metrics that demonstrate the controls are operating effectively and improving over time. The documented processes are the SDLC process documentation, secure coding standards, and code review checklist. The evidence of operation is the CI/CD security gate configuration (showing the gates exist), the findings history (showing the gates are generating findings and those findings are being remediated), and the developer training records (showing that training occurred). The metrics are the security metrics dashboard showing finding trends, mean time to remediate, and compliance gate pass rates over the audit period.

Organizations that prepare this evidence package before an audit, rather than reconstructing it during the audit, navigate compliance assessments materially faster and with fewer findings. The DevSecOps engagement produces all of these artifacts as standard deliverables: process documentation structured for audit use, a compliance mapping that connects each program component to the applicable framework requirement, and a metrics dashboard designed to produce the operating effectiveness evidence that Type II assessments require. Armour Cybersecurity aligns each DevSecOps engagement to the compliance frameworks applicable to the organization and structures deliverables for direct use during audit.

Frequently Asked Questions

Do we need DevSecOps if we use a third-party application rather than building our own?

If the organization builds any custom software, even internal tools or integrations with third-party applications, the secure development controls apply to that custom software. For organizations that use only third-party applications and build no custom code, the relevant compliance controls shift from secure development to third-party software management: ensuring that the third-party applications are kept patched, that vendors are assessed for their own security practices, and that the applications are configured securely. SCA is still relevant for organizations that use third-party applications, because those applications have their own dependency vulnerability posture that the organization should understand as part of vendor risk management. The DevSecOps engagement focuses on the custom software development lifecycle; vendor security assessment is addressed through the supplier risk management program.

What is the difference between a SOC 2 Type I and Type II assessment for DevSecOps controls?

A SOC 2 Type I assessment evaluates whether security controls are suitably designed at a specific point in time. It answers: does this organization have a secure SDLC in place with the right components? A SOC 2 Type II assessment evaluates whether those controls operated effectively over a period of time, typically six or twelve months. It answers: did this organization’s secure SDLC actually function as described throughout the audit period? For DevSecOps controls, Type I is satisfied by implementing the program and documenting the design. Type II is satisfied by the ongoing operation of the program, evidenced by the metrics dashboard showing that security gates ran on every pull request, findings were generated and remediated, and training occurred during the audit period. A DevSecOps program implemented immediately before a Type II audit period begins will satisfy Type II if it operates correctly throughout the period; a program implemented halfway through the audit period will show a gap in operating history for the first half.

How does DevSecOps interact with change management requirements?

Change management requirements in SOC 2 (CC8.1) and ISO 27001 (A.8.32) require that changes to systems and software follow a defined and controlled process that includes testing and approval before deployment to production. A CI/CD pipeline with defined security gates and branch protection rules that require code review and passing security checks before merge to the main branch is a change management control: it enforces that every change to production software has been reviewed, tested, and approved before deployment. The pipeline configuration, combined with the branch protection settings in the version control system, provides the documented change management process and the evidence of its operation that auditors look for in this control domain.

What is threat modeling and when is it required for compliance?

Threat modeling is a structured process for identifying security threats to a system during the design phase, before any code is written, so that security requirements can be built into the architecture rather than retrofitted after the fact. It involves defining the system, its data flows, trust boundaries, and the potential threats relevant to each component, then designing controls to address the identified threats. Threat modeling is referenced in NIST SP 800-218, PCI DSS Requirement 6.2 (which requires security requirements to be identified prior to development), and ISO 27001 A.8.26 (application security requirements). It is most valuable for new applications or significant new features that involve sensitive data processing, authentication changes, or new integrations. Armour Cybersecurity delivers a lightweight threat modeling process template and facilitator guidance as part of the DevSecOps engagement, designed to be embedded into the architecture review stage of the SDLC without requiring significant time investment for routine changes.

The Bottom Line

Every framework that touches a software-building organization asks the same question in different language: show me that the software itself was built securely, not just that the servers it runs on are locked down. SOC 2 asks through CC8.1 change management and CC7.1 vulnerability detection, ISO 27001 through the A.8.25 to A.8.31 secure development controls, PCI DSS through the detailed Requirement 6, and HIPAA through the technical safeguards that application vulnerabilities can undermine. The answer to all of them is the same artifact set: documented SDLC processes, configured CI/CD security gates, a findings history with remediation records, developer training records, and a metrics dashboard that proves the controls operated across the audit period, not just on the day the auditor arrived. A structured DevSecOps program produces that evidence as a byproduct of running the pipeline, which turns the application-security control domain from the predictable audit gap it usually is into one of the easier parts of the assessment to pass.