Compliance Security Testing: SOC 2 & ISO 27001

Your auditor asks: "What security testing do you perform?" The answer needs to map directly to the compliance framework you're certifying against. But every framework describes requirements differently, and none of them give you a clear testing checklist. We've done the mapping across the three frameworks our customers ask about most.

SOC 2: What the Trust Services Criteria Actually Require

SOC 2 is organized around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most companies focus on the Security criterion (CC — Common Criteria).

Testing Requirements for SOC 2 Security

The specific criteria that map to penetration testing:

• CC7.1 — Detection: "The entity monitors system components and the operation of those components for anomalies." This means you need to demonstrate that you can detect attacks, which BAS and internal testing validate.
• CC7.2 — Response: "The entity monitors system components for anomalies that are indicative of malicious acts, natural disasters, and errors." Your incident response process should be triggered by testing findings.
• CC4.1 — Monitoring: "COSO principle 16 — the entity selects, develops, and performs ongoing evaluations." This is your license for continuous security testing.
• CC3.2 — Risk Assessment: "The entity identifies risks to the achievement of its objectives." Penetration testing is the most concrete form of risk identification.

SOC 2 doesn't prescribe specific testing methodologies or frequencies. It requires that you demonstrate a security testing program exists and that findings are tracked to remediation. Most auditors accept:

1. Annual external penetration test (at minimum)
2. Quarterly vulnerability scanning
3. Evidence that findings are triaged, prioritized, and remediated
4. A defined process for retesting after remediation

ISO 27001: Annex A Controls That Require Testing

ISO 27001:2022 reorganized its controls into four themes: Organizational, People, Physical, and Technological. The testing-relevant controls are primarily in the Technological theme:

• A.8.8 — Management of technical vulnerabilities: "Information about technical vulnerabilities of information systems in use shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken." This mandates vulnerability management, including scanning and testing.
• A.8.9 — Configuration management: Requires baseline configurations and regular validation. Security testing verifies that configurations match security baselines.
• A.8.25 — Secure development lifecycle: Requires security testing as part of the SDLC. DAST, SAST, and penetration testing all satisfy this.
• A.8.34 — Protection of information systems during audit testing: When you perform security tests, protect the system from unintended damage. Scope controls and safe testing practices.

ISO auditors typically want to see:

1. A documented vulnerability management policy with defined testing frequency
2. Evidence of regular security testing (reports from the past 12 months)
3. A risk treatment plan that maps testing findings to remediation actions
4. Evidence that testing covers both internal and external attack surfaces

NIS2: The European Directive That Changes Everything

The EU's NIS2 Directive (Network and Information Security Directive 2) came into force in October 2024 and applies to a much broader set of organizations than its predecessor. If you operate in the EU or serve EU customers in essential or important sectors, NIS2 likely applies to you.

NIS2 Security Testing Requirements

Article 21 of NIS2 requires "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." Specifically:

• Risk analysis and information system security policies
• Incident handling and reporting (within 24 hours for significant incidents)
• Business continuity and crisis management
• Supply chain security (your vendors' security becomes your problem)
• Security in network and information systems acquisition, development, and maintenance — including vulnerability handling and disclosure
• Policies and procedures to assess the effectiveness of cybersecurity risk-management measures

That last point — assessing effectiveness — is the testing mandate. NIS2 doesn't prescribe penetration testing by name, but the ENISA implementation guidance explicitly recommends:

1. Regular vulnerability assessments and penetration testing
2. Red team exercises for critical infrastructure operators
3. Continuous monitoring and automated security testing
4. Supply chain security assessments

NIS2 Penalties

NIS2 has real teeth. Essential entities face fines up to EUR 10 million or 2% of global annual turnover, whichever is higher. Important entities face up to EUR 7 million or 1.4% of turnover. Management can be held personally liable for non-compliance.

Mapping Frameworks to Testing Activities

Here's how specific testing activities map across all three frameworks:

• External penetration testing: Required by all three. Annual minimum for SOC 2 and ISO 27001. NIS2 implies continuous or frequent.
• Internal penetration testing: Strongly implied by ISO 27001 (A.8.8) and NIS2 (Article 21). SOC 2 auditors increasingly expect it.
• Vulnerability scanning: Quarterly for SOC 2. Continuous for ISO 27001 and NIS2 best practices.
• Application security testing (DAST/SAST): Required by ISO 27001 A.8.25. Implied by SOC 2 CC7.1. Required by NIS2 for essential entities.
• Breach and attack simulation: Validates detection capabilities for SOC 2 CC7.1/CC7.2 and NIS2 incident handling requirements.

Practical Implementation

Rather than running separate testing programs for each framework, implement a unified security testing program that satisfies all three:

1. Continuous vulnerability scanning with automated triage and tracking
2. Monthly autonomous penetration testing (external and internal) — satisfies the most demanding framework's requirements
3. Application security testing integrated into CI/CD
4. Quarterly review of testing coverage, findings trends, and remediation metrics
5. Annual comprehensive report mapping findings and testing activities to specific framework controls

Compliance frameworks tell you what to test. The testing itself tells you whether your security actually works. Use the frameworks as a floor, not a ceiling. The goal isn't to pass the audit — it's to prevent the breach that triggers the audit.

NeuroStrike's on-prem deployment generates compliance-ready reports that map findings directly to SOC 2 criteria, ISO 27001 controls, and NIS2 requirements. The same testing program, presented in the language each auditor expects.