Compliance vs Security Gap

In 2013, Target Corporation's payment systems were breached through the compromise of an HVAC vendor's network access credentials , an entry point that was not within the scope of Target's PCI-DSS cardholder data environment assessment. The CDE was well-protected and had passed its most recent QSA assessment. The HVAC vendor's access provided a foothold in Target's corporate network, from which the attackers pivoted to the point-of-sale systems. The PCI-DSS compliance programme had correctly confirmed controls on the in-scope cardholder data environment. The breach occurred through an adjacent pathway that compliance had not assessed. Target was PCI-DSS compliant. Target was breached. The compliance programme had fulfilled its mandate , assessing the defined scope against the defined requirements. The security posture that the compliance assessment was supposed to proxy had a gap that the compliance framework was not designed to detect.

What is the Compliance vs Security Gap, Really?

Compliance is the state of conformance with a defined set of requirements , a standard, a regulation, a framework , for a defined scope at a point in time. Security is the ongoing resistance to actual threats across the full attack surface. Compliance frameworks are designed by committees working from threat models that reflect the threats considered at the time of the framework's development. They define minimum requirements that, when implemented, provide a baseline of security for the defined scope. They are not designed to address every actual threat, every emerging attack technique, or every adjacent system that might provide a pathway to the regulated scope.

The scope boundary problem is the most practically consequential compliance-security gap. Compliance frameworks define in-scope environments , the cardholder data environment in PCI-DSS, the production systems in SOC 2, the ISMS in ISO 27001. Controls are assessed for the in-scope environment. The out-of-scope systems that are adjacent to, connected to, or can reach the in-scope environment are not assessed by the compliance framework. An attacker who compromises an out-of-scope system and uses it as a pivot to reach the in-scope environment has exploited a gap that compliance was not designed to close , the gap between the compliance scope boundary and the full network and access perimeter that actually determines what can reach the protected environment.

The point-in-time problem is the second compliance-security gap. Compliance assessments are conducted at defined intervals , annually for PCI-DSS, on defined cycles for SOC 2. They confirm compliance at the assessment date. The environment changes continuously between assessments , new systems deployed, new integrations added, new access pathways created. A compliance assessment that confirms all required controls were in place at the last assessment date does not confirm that those controls are still in place eleven months later, or that the new systems deployed since the assessment have been governed with equivalent controls.

• Compliance scope boundary as attack surface gap , out-of-scope systems providing pathways to in-scope environments
• Point-in-time assessment vs continuous threat , compliance confirmed at assessment date does not reflect intervening changes
• Framework minimum requirements vs actual threat landscape , compliance requirements designed for baseline threats, not emerging attack techniques
• Compensating controls accepted by compliance that do not address actual threats , compliance-satisfying alternatives that do not reduce operational risk
• Compliance as security proxy , customer treating compliance confirmation as security confirmation

Why this matters

Compliance versus security matters for TPRM because compliance certifications are the most commonly used third-party evidence in vendor security assessments , and they systematically have the limitations described. Every SOC 2 report, ISO 27001 certificate, and PCI-DSS attestation is a genuine, valuable piece of evidence about the vendor's security programme for the defined scope at the assessment date. None of them is a comprehensive security assurance that extends beyond the defined scope and the assessment date.

The risk of treating compliance as a security proxy scales with the gap between the compliance framework's scope and requirements and the actual threat landscape of the vendor relationship. For a vendor whose threat landscape is well-captured by the compliance framework's requirements and scope, the proxy is reasonably accurate. For a vendor whose significant risks are in out-of-scope systems, emerging threat categories not covered by the framework, or post-assessment changes, the proxy may significantly overstate the actual security assurance.

Where most teams get this wrong

The most consistent failure is treating compliance confirmation as security confirmation without asking about what is outside the compliance scope and what has changed since the most recent assessment. Compliance answers the scope-and-date bounded question. Security requires scope-complete and continuously current answers.

• Treating compliance confirmation as security confirmation
• Out-of-scope systems not assessed , adjacent and connected systems outside compliance boundary
• No post-assessment change assessment , environment changes since the compliance assessment date
• Framework minimum requirements accepted as sufficient , not asking whether controls exceed minimums or address emerging threats
• Compliance framework scope gaps not identified , attack categories the framework was not designed to address

What good looks like

Mature TPRM programmes use compliance certifications as a foundation and supplement them with targeted assessment of the gaps the compliance framework was not designed to address , specifically, adjacent out-of-scope systems that can reach the in-scope environment, post-assessment changes that may have affected the compliant state, and emerging threat categories not captured by the framework's minimum requirements.

• Compliance plus gap assessment , compliance as foundation, targeted assessment of scope gaps and post-assessment changes
• Adjacent system assessment , systems outside compliance scope that can reach in-scope environments
• Post-assessment change review , what has changed since the most recent compliance assessment
• Emerging threat assessment , attack categories the compliance framework does not address
• Continuous monitoring , real-time security signals alongside periodic compliance assessments

Tooling

Continuous Security Monitoring , BitSight, SecurityScorecard

Security rating platforms provide continuous external signals of security posture between compliance assessment cycles , detecting vulnerabilities, misconfigurations, and security incidents that emerge after compliance assessments. For TPRM practitioners, incorporating continuous security ratings alongside compliance certifications provides the post-assessment monitoring that point-in-time assessments cannot.

Attack Surface Management , Tenable, Qualys

Attack surface management platforms continuously inventory and assess external attack surface , including systems that may be adjacent to compliance-scoped environments. For TPRM practitioners, asking whether vendors conduct continuous attack surface management provides a specific post-assessment monitoring capability question.

Governance challenges

The governance challenge with compliance versus security is the standards dependency. Compliance frameworks provide a shared vocabulary, defined requirements, and independent verification that makes compliance assessment administratively efficient. Replacing compliance with bespoke security assessment for every vendor would be operationally infeasible. The governance resolution is not to abandon compliance evidence but to supplement it with targeted gap assessment , using compliance as a foundation and applying additional assessment to the dimensions it does not cover.

• Use compliance as a foundation, not a ceiling , compliance confirms the baseline; gap assessment determines whether the baseline is sufficient
• Identify and assess out-of-scope systems that connect to compliance-scoped environments
• Ask what has changed since the most recent assessment
• Incorporate continuous security monitoring alongside periodic compliance
• Identify framework gaps , attack categories the applicable framework was not designed to address

If you are a small team

For your highest-risk PCI-DSS or SOC 2 compliant vendors, ask two questions that compliance does not answer. First: what systems outside the compliance scope boundary have network or access connectivity to the in-scope environment , and have those systems been assessed with equivalent controls? Second: what significant changes have been made to the environment since the most recent compliance assessment, and have those changes been assessed against the compliance requirements? Those two questions address the scope gap and the point-in-time gap that compliance assessments do not close.

• Ask what out-of-scope systems have connectivity to the in-scope environment
• Ask what has changed since the most recent compliance assessment
• Incorporate continuous security monitoring alongside compliance reliance
• Identify and directly assess compliance framework scope gaps

What to require

Ask directly:

"What systems outside your PCI-DSS or SOC 2 compliance scope have network or access connectivity to your in-scope environment , and have those adjacent systems been assessed with security controls equivalent to those required within the compliance scope?"

"What significant changes have been made to your environment since your most recent compliance assessment , including new systems deployed, new integrations added, and network changes , and have those changes been assessed for compliance impact?"

Expect as evidence

• Out-of-scope adjacent system inventory with connectivity to in-scope environment
• Post-assessment change log with compliance impact assessment
• Continuous security monitoring confirmation
• Scope gap identification and compensating assessment

A vendor who confirms PCI-DSS compliance should be asked what out-of-scope systems have access to the cardholder data environment. The compliance assessment confirmed the CDE. The adjacent systems are the question the compliance assessment did not address.

How to evidence it

• Out-of-scope system assessment records
• Post-assessment change review records
• Continuous security monitoring integration
• Compliance gap supplementary assessment records

Key Takeaway

Compliance confirms conformance with defined requirements for a defined scope at a point in time. Security requires resistance to actual threats across the full attack surface continuously. The PCI-DSS compliance assessment confirmed every required control in the cardholder data environment. The breach came through the HVAC vendor's access to an adjacent system. The compliance scope boundary was accurate. The attack surface did not honour it. Compliance is a foundation. The gap between the foundation and the actual security posture is determined by what is outside the scope and what has changed since the assessment. Neither is captured by the compliance certificate. Both require additional assessment.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations