AppSec Compliance Mapping

Why compliance drives AppSec investment

Compliance is the most common reason organizations start investing in application security tooling. Not because compliance produces the best security outcomes, but because it creates a budget line item and a deadline.

A Gartner survey found that regulatory compliance was the primary driver for security spending in 67% of organizations. SOC 2 audits, PCI DSS assessments, and customer security questionnaires force engineering teams to implement scanning tools and fix-it processes they might otherwise put off.

The relationship between compliance and security is imperfect. Passing an audit does not mean your applications are secure. Plenty of compliant organizations have been breached. But compliance frameworks give you a usable baseline: what to scan, how often, and how fast to fix what you find. That structure helps even when the bar is lower than where your security program should aim.

This guide maps specific compliance controls to the AppSec tools and practices that satisfy them. Use it to figure out what your framework actually requires and avoid buying more than you need.

SOC 2

SOC 2 is a Trust Services framework from the AICPA. It evaluates controls across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For application security, Security and Confidentiality matter most.

SOC 2 does not prescribe specific tools. It requires you to show that controls exist, work, and are monitored over the audit period (typically 12 months for Type II).

Key controls for AppSec

CC6.1 — Logical and physical access controls. Secure your code repositories and CI/CD pipelines. Enforce branch protection, require code reviews, and use role-based access. Evidence: GitHub/GitLab audit logs showing access controls, branch protection rules, and PR review requirements.

CC7.1 — Monitor infrastructure and software for vulnerabilities. Run security scans against your applications. SAST in CI/CD and DAST against deployed applications satisfy this control. Evidence: scan reports showing regular execution and finding remediation.

CC7.2 — Monitor for anomalies and events. Application logging, error monitoring, and runtime protection. RASP tools and application-level WAFs contribute here. Evidence: log aggregation dashboards, alerting configs, and incident response records.

CC8.1 — Change management. Document your SDLC. Show that code changes go through review and testing before deployment. Evidence: PR history, CI/CD pipeline configs, and deployment approval workflows.

C1.1 — Confidential information protection. Prevent secrets from leaking into code repositories. Secret scanning tools like GitGuardian, Gitleaks, or TruffleHog cover this. Evidence: secret scanning configs and remediation records.

What auditors actually look for

SOC 2 auditors want to see process, not perfection. They want evidence that:

1. You have defined a secure development lifecycle
2. Security testing runs regularly (not just once a year)
3. Findings are tracked and remediated within defined timelines
4. You can produce logs showing the process operated over the audit period

A small team running Semgrep in CI, ZAP weekly, and GitHub Issues for tracking can pass a SOC 2 audit. The specific tools matter less than having a documented process and actually following it.

PCI DSS

PCI DSS 4.0 (effective March 2025, with some requirements extended to March 2026) has the most specific application security requirements of any major compliance framework. Requirement 6 covers secure software development. Requirement 11 covers vulnerability scanning.

Requirement 6: Develop and maintain secure systems

6.2.1 — Bespoke and custom software are developed securely. Establish a secure development process. Train developers on secure coding. This is process-level: document your SDLC and show that developers know how to avoid OWASP Top 10 vulnerabilities.

6.2.2 — Software development personnel receive training on secure coding. Annual security training with relevance to your technology stack. Third-party training platforms or internal sessions both satisfy this.

6.2.3 — Bespoke and custom software is reviewed prior to release. Code reviews that specifically evaluate security. This can be manual code review by a trained developer, automated SAST scanning, or a combination. Evidence: PR review logs, SAST scan reports per release.

6.2.4 — Software engineering techniques or other methods prevent or mitigate common software attacks. Technical testing for OWASP Top 10 categories. SAST covers code-level issues. DAST covers runtime behavior. Most QSAs expect evidence of both.

6.3.1 — Security vulnerabilities are identified and managed. Track known vulnerabilities in your software, including open-source components. SCA tools satisfy this by monitoring dependencies for known CVEs. Evidence: SCA scan reports and remediation records.

6.3.2 — An inventory of bespoke and custom software is maintained. Know what software you have and what components it uses. Software bill of materials (SBOM) generation covers this. SCA tools and SBOM generators like Syft and CycloneDX satisfy this requirement.

Requirement 11: Regular security testing

11.3.1 — External vulnerability scans by an ASV quarterly. These are infrastructure/network scans by an Approved Scanning Vendor. Not application-specific, but relevant if your web applications are in scope.

11.3.1.1 — Internal vulnerability scans at least quarterly. Internal scanning of your cardholder data environment. DAST scans of internal applications can contribute here.

11.3.2 — Penetration testing annually. Application-layer penetration testing at least once a year and after significant changes. Automated DAST is not a substitute. PCI DSS specifically requires manual or methodology-driven penetration testing.

Practical approach

For PCI DSS compliance: run SAST on every pull request for Requirement 6.2.3/6.2.4. Run SCA continuously for 6.3.1/6.3.2. Schedule DAST scans quarterly at minimum for 11.3.1.1. Engage a penetration testing firm annually for 11.3.2. Keep records of everything.

HIPAA

HIPAA’s Security Rule requires covered entities and business associates to implement technical safeguards protecting electronic protected health information (ePHI). HIPAA is less specific than PCI DSS about security testing, but the expectation is clear: if your application handles health data, you need to test it for vulnerabilities.

Relevant technical safeguards

§164.312(a) — Access control. Implement technical policies and procedures to allow access only to authorized persons. For application security, this means testing authentication and authorization logic. DAST authenticated scanning and manual penetration testing verify access controls.

§164.312(c) — Integrity. Protect ePHI from improper alteration or destruction. Security testing catches injection flaws and logic errors that could allow unauthorized data modification. SAST and DAST cover the vulnerability classes most likely to cause data integrity problems.

§164.312(d) — Person or entity authentication. Verify the identity of users accessing ePHI. Test your authentication mechanisms for common weaknesses: default credentials, session management flaws, brute force susceptibility. DAST scanners test for these automatically.

§164.312(e) — Transmission security. Protect ePHI during electronic transmission. TLS configuration testing, certificate validation, and encryption verification. DAST tools check TLS configuration as part of standard scans.

§164.308(a)(1) — Risk analysis and management. Conduct an accurate assessment of risks and vulnerabilities to ePHI. Running SAST, DAST, and SCA regularly feeds into your risk analysis by surfacing technical vulnerabilities.

What HIPAA auditors expect

HIPAA audits are less prescriptive than PCI DSS about specific tools. Auditors want to see that you ran a risk assessment, found vulnerabilities, and implemented reasonable security measures. “Reasonable” is interpreted based on your organization’s size and the sensitivity of the ePHI involved.

At minimum: regular vulnerability scanning of applications that handle ePHI, documented remediation of findings, and evidence that security is part of your development process. Annual penetration testing is an industry expectation even though HIPAA does not explicitly require it.

ISO 27001

ISO 27001:2022 is an international standard for information security management systems. Annex A defines controls, and several apply directly to application security.

Relevant Annex A controls

A.8.25 — Secure development lifecycle. Establish rules for secure software development. Document your SDLC, include security activities at each phase, and train developers. Evidence: SDLC documentation, training records, and security gate criteria.

A.8.26 — Application security requirements. Define security requirements when building or buying applications. Threat modeling and security acceptance criteria in user stories satisfy this. Evidence: security requirements documents and threat model outputs.

A.8.27 — Secure system architecture and engineering principles. Apply security principles to system design. Documented architecture decisions and security design reviews fall under this control. It is broader than scanning but includes the results of security testing.

A.8.28 — Secure coding. Apply secure coding practices. SAST enforcement in CI/CD, coding standards documentation, and developer training all count. Evidence: SAST scan configs, coding standards, and CI/CD pipeline definitions with security gates.

A.8.8 — Management of technical vulnerabilities. Find and fix technical vulnerabilities on time. This is the broadest vulnerability management control. Regular scanning with SAST, DAST, and SCA, plus a documented remediation process with SLAs. Evidence: scan schedules, remediation records, and SLA compliance reports.

A.8.29 — Security testing in development and acceptance. Define and run security testing procedures. Automated scanning (SAST, DAST) and manual security reviews both count. Evidence: test plans, scan reports, and security review records.

Certification approach

ISO 27001 auditors evaluate whether your information security management system (ISMS) addresses risks appropriately. They expect proportional controls. A startup processing low-sensitivity data needs different tooling than a bank.

Document your approach, run your tools consistently, and track your findings. Be ready to show the evidence trail during the audit. The standard cares about the management system as much as the technical controls themselves.

Mapping tools to compliance controls

This table shows which AppSec tool types satisfy which compliance controls.

Minimum viable toolset by framework

SOC 2: SAST in CI + DAST quarterly + documented SDLC + finding tracker.

PCI DSS: SAST in CI + DAST quarterly + SCA continuous + annual pentest + ASV quarterly scans.

HIPAA: SAST in CI + DAST quarterly + risk assessment documentation + annual pentest (recommended).

ISO 27001: SAST in CI + DAST periodically + SCA + documented ISMS with vulnerability management procedures.

Automating compliance evidence collection

Manual evidence collection is tedious and error-prone. Every quarter, someone gathers scan reports, screenshots of pipeline configs, and remediation tickets into a folder. It does not scale.

What to automate

Scan execution logs. CI/CD pipelines already log every SAST and DAST scan. Export these to a central location with timestamps, scan configs, and result summaries.

Finding lifecycle tracking. When a vulnerability is found, triaged, assigned, fixed, and verified, record each state change with a timestamp. ASPM tools do this automatically. Issue trackers with custom workflows can get you most of the way there.

SLA compliance reports. Calculate remediation time from discovery to closure for each finding. Compare against your SLAs and flag violations. A script querying your issue tracker API can generate this.

Coverage dashboards. Which applications have active SAST? DAST? SCA? A coverage dashboard shows the gaps that auditors will ask about. Build it from your CI/CD configurations or your ASPM platform.

Tool recommendations for evidence automation

Commercial ASPM platforms like ArmorCode, Apiiro, and Ox Security ingest findings from all your scanners, track remediation, and generate compliance-specific reports. Most expensive option, but the least manual effort.

GRC platforms with AppSec integration like Drata, Vanta, and Secureframe pull evidence from your security tools via API integrations. Good fit for teams that need compliance automation across the whole organization, not just AppSec.

DIY automation using scripts that pull data from your scanner APIs, issue tracker, and CI/CD system into a reporting database. Free, but you need engineering time to build and maintain it. Works well for teams with strong engineering culture and limited budget.

For most growing organizations, a GRC platform handles audit preparation while the individual security tools (SAST, DAST, SCA) do the actual scanning. The GRC platform pulls evidence from those tools automatically.

For pricing details across these tools, see our AppSec pricing guide. For building the program around them, see the DevSecOps program guide.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.