SOC 2, PCI DSS, GDPR: How Engineering Leaders Prepare for Compliance Audits with Attack Simulation

The compliance testing gap engineering leaders face

When a CTO, Director of Engineering, or VP of Engineering starts a compliance program — SOC 2 for enterprise sales, PCI DSS for payment processing, GDPR for EU customers — they quickly hit the same problem: auditors want evidence that specific technical controls work, not just evidence that you ran a scan.

A vulnerability scanner that produces a list of CVEs does not map to SOC 2 CC6 or PCI DSS Requirement 6. An annual penetration test produces a PDF that covers a point in time, not continuous evidence of testing across your deployment cycle. And most engineering teams don't have the bandwidth to manually translate security findings into the control language each framework requires.

The result is a common pattern: security testing and compliance preparation run as separate workstreams — one owned by engineering, one owned by legal or operations — and the gap between them creates friction with auditors, slows certification timelines, and produces documentation that needs to be rewritten before it's usable.

Compliance-aligned attack simulation closes this gap by running security tests against the specific technical controls each framework requires, mapping findings to control references automatically, and producing evidence in a format auditors can directly use.

What auditors actually need from security testing

Across all major frameworks, the technical security testing requirements share a common structure. Auditors want to see:

• Evidence of access control testing — proof that authentication, session handling, and authorization controls were actively tested, not just documented
• Evidence of input validation testing — demonstration that injection paths (SQL, command, header) were exercised against production-equivalent environments
• Evidence of encryption in transit — TLS configuration tested and validated, not assumed
• Repeatable testing cadence — evidence that testing happens on a defined schedule or in response to significant changes, not just once
• Remediation tracking — findings linked to fixes, with timestamps showing how long vulnerabilities remained open

The difference between a compliant and non-compliant security program often isn't the absence of security — it's the absence of documentation that proves the security exists and was tested. Attack simulation that maps to framework controls produces this documentation as a natural output of each run.

The five compliance frameworks and what they require technically

SOC 2 Type II — the SaaS standard

SOC 2 Type II is the compliance framework most B2B SaaS companies pursue first, because enterprise customers require it before signing contracts. The Trust Services Criteria most relevant to engineering are CC6 (logical and physical access controls), CC7 (system operations), and CC8 (change management).

For CC6, auditors look for evidence that access controls — authentication, authorization, session management — are tested and functioning. For CC7, they look for evidence that the system is monitored and that security events are detected. For CC8, they want to see that changes go through a security review process.

Attack simulation covers CC6 directly: tests for authentication bypass, IDOR, session hijacking, and API access control failures produce findings that map to the criteria and generate evidence of testing. The simulation report, with its HTTP-level proof and timestamps, serves as the testing record auditors require.

PCI DSS 4.0 — payment data environments

PCI DSS Requirement 6 (develop and maintain secure systems) and Requirement 11 (test security of systems and networks regularly) are the most directly relevant to engineering teams. Requirement 11.3 specifically mandates penetration testing of the application layer at least annually and after significant changes.

The PCI DSS compliance preset exercises the full attack surface required by Requirements 6 and 11: TLS validation, header analysis, injection testing, authentication abuse, business logic testing, login rate limit and lockout testing, and API discovery. Each test is logged with the HTTP request and response evidence needed to demonstrate active testing to a Qualified Security Assessor.

Running the PCI DSS preset after each significant change to your cardholder data environment satisfies the "after significant change" requirement and builds a continuous testing record that simplifies the annual QSA review.

GDPR Article 32 — security of processing

GDPR Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." This is deliberately vague — the regulation doesn't specify which tests to run — but supervisory authorities expect evidence of a systematic approach.

The GDPR compliance preset maps to the technical controls most commonly examined in GDPR audits: encryption in transit (TLS), access control and authentication (authTesting, IDOR), injection vulnerabilities, and AI-assisted data exposure analysis — particularly relevant if your application processes personal data through AI features.

For GDPR purposes, the simulation report serves dual purposes: it demonstrates the "regular testing" requirement and, if findings are remediated, it documents the "evaluating effectiveness of measures" requirement. Both are evidence that supervisory authorities look for when assessing Article 32 compliance.

HIPAA Security Rule — electronic protected health information

45 CFR §164.312 (Technical Safeguards) requires covered entities and business associates to implement access controls, audit controls, integrity controls, and transmission security for systems handling ePHI. The Security Rule also requires periodic technical and non-technical evaluation of implemented safeguards under §164.308(a)(8).

The HIPAA compliance preset targets the technical safeguards directly: authentication testing, session integrity, API access control, injection paths that could expose ePHI, and TLS configuration. For covered entities building health applications, running this preset before deployment and after significant changes provides the periodic evaluation evidence §164.308(a)(8) requires.

ISO 27001:2022 — information security management

ISO 27001:2022 Annex A.12 (Operations Security) and Annex A.14 (System Acquisition, Development and Maintenance) require organizations to monitor systems for security events and to test security throughout the development lifecycle. Annex A.14.2.8 specifically requires security testing during development.

The ISO 27001 preset covers the Annex A controls most directly tied to web application security: vulnerability management, secure coding validation, transmission security, and access control testing. For organizations pursuing ISO 27001 certification, integrating the preset into the CI/CD pipeline or pre-release checklist provides continuous evidence of Annex A compliance.

How compliance presets work in practice

In Nautillo Pro, compliance presets are pre-configured simulation profiles that enable the specific attack techniques each framework requires. When you select a preset — say, SOC 2 Type II — the simulation automatically enables the tests mapped to CC6, CC7, and CC8, runs them against your target, and produces a report with findings labeled by their compliance relevance.

The output includes:

• Which tests were run and which controls they correspond to
• Confirmed findings with HTTP-level proof of exploitation
• Each control shown as PASS or NOT TESTED in the compliance coverage section — colour-coded, one line per requirement (e.g., PCI DSS Req. 6.4.3, SOC 2 CC6.1)
• MITRE ATT&CK technique mapped to every confirmed finding
• Exportable PDF and JSON reports suitable for audit documentation packages

This means engineering leaders can hand the report directly to their compliance team, legal counsel, or external auditor without translation. The control mapping is done by the simulation, not by an engineer spending a day reformatting findings.

What compliance presets don't replace

This is important to state clearly: compliance-aligned attack simulation is preparation evidence, not certification. No automated tool can certify compliance with SOC 2, PCI DSS, GDPR, HIPAA, or ISO 27001. Each framework has requirements that extend well beyond technical security testing — vendor management, employee training, physical security, incident response procedures, and policy documentation.

What compliance presets provide is:

• Evidence of active security testing against the technical controls each framework requires
• Repeatable, documented testing cadence auditors can verify
• Findings in a format that supports the remediation tracking auditors look for
• Reduction in the gap between your engineering security work and your compliance documentation

For formal certification — SOC 2 Type II report from a licensed CPA firm, QSA assessment for PCI DSS, BSI or UKAS audit for ISO 27001 — you will need qualified professionals. The simulation evidence supports their work; it doesn't replace it.

When to integrate compliance presets into your engineering workflow

The highest-value integration points are:

• Before entering a formal audit process — running compliance presets 60–90 days before an audit gives you time to find and fix issues before auditors do, and starts building the testing record they'll want to see
• After significant system changes — PCI DSS Requirement 11.3 and SOC 2 CC8 both require testing after significant changes; compliance presets provide supporting evidence for this requirement when run post-deployment
• Quarterly review cycles — running a compliance preset every quarter builds the continuous testing evidence that distinguishes a mature security program from a point-in-time check
• When responding to customer security questionnaires — enterprise customers increasingly ask for evidence of security testing, not just SOC 2 reports; simulation reports with compliance mapping are a direct answer

Availability

Compliance presets are available on the Nautillo Pro Business plan. The Business plan includes access to all seven compliance frameworks (PCI DSS 4.0, HIPAA, GDPR Article 32, SOC 2 Type II, ISO 27001:2022, OWASP Top 10 2021, NIST CSF 2.0), along with the full suite of attack techniques each preset requires — login rate limit and lockout testing, advanced API exploit paths, business logic testing, AI-assisted data exposure analysis, and full-domain simulation.

The compliance preset feature is currently in Beta. Reports include control mapping and audit-ready PDF export. JSON export is available for teams integrating simulation results into their compliance tooling.