EASM for Compliance: PCI DSS, NIS2, and SOC 2
External attack surface data supports compliance work by evidencing what you expose and how it changes: a current inventory of internet-facing assets, timestamped scan history across the audit period, and a log of detected changes. It supports controls in PCI DSS, NIS2, and SOC 2 — your assessor, not a tool, determines compliance.
Auditors are no longer satisfied with annual penetration tests. Compliance frameworks now demand continuous visibility into your external attack surface. This guide maps EASM capabilities directly to the controls that auditors check, so you can turn scan data into audit evidence.
- Why auditors now ask about external attack surface visibility
- Specific PCI DSS 4.0, NIS2, and SOC 2 controls that EASM supports
- How to map EASM capabilities to framework requirements
- What to export and present during compliance audits
- A 4-step plan to prepare compliance evidence today
14 min read
Why Auditors Are Asking About Your External Attack Surface
The compliance landscape has shifted. Five years ago, auditors checked whether you had a firewall and ran an annual vulnerability scan. Today they want to know whether you have continuous visibility into every internet-facing asset your organization exposes, and whether you can demonstrate that visibility with data.
Three forces are driving this change:
- Breach patterns have changed. Unmonitored and forgotten external assets are a recurring theme in incident reporting, and auditors have noticed. They now ask specifically about unknown asset discovery and configuration drift.
- Regulatory frameworks have updated. PCI DSS 4.0 introduced new requirements for external vulnerability management that took full effect in March 2025. NIS2 enforcement had an October 2024 transposition deadline across EU member states. Both explicitly reference continuous risk assessment and asset inventory obligations.
- Point-in-time evidence is no longer sufficient. An annual penetration test report shows your posture on a single day. Auditors increasingly expect evidence of ongoing monitoring: trend data, change detection logs, and scheduled scan histories that cover the entire audit period.
External Attack Surface Management (EASM) directly addresses these expectations. It provides the continuous discovery, vulnerability assessment, and change tracking data that auditors want to see, organized in a format they can review during control testing.
EASM tools support compliance workflows and help generate evidence for auditors. They do not guarantee compliance with any framework. Compliance is determined by auditors based on your complete control environment, organizational policies, and implementation maturity. Always consult your compliance team or qualified assessor for authoritative guidance.
Which Compliance Frameworks Require Continuous ASM
Three major frameworks are driving the most demand for EASM evidence. Each approaches external attack surface visibility from a different angle, but all converge on the same principle: you must know what you expose and monitor it continuously.
PCI DSS v4.0.1: External Scanning and Asset Inventory
PCI DSS v4.0.1 is the current version; v4.0's future-dated requirements became effective in March 2025. It places explicit emphasis on maintaining an accurate inventory of system components and performing regular external vulnerability scans. Three requirements are particularly relevant to EASM:
- Requirement 6.3 (Security vulnerabilities are identified and addressed): Organizations must identify and manage security vulnerabilities through a formal process. This includes monitoring vulnerability advisories and correlating them against your asset inventory. EASM provides the external asset catalog and vulnerability scan results that feed this process.
- Requirement 12.5.1 (An inventory of system components in scope for PCI DSS is maintained and kept current): this is the control that asks for a complete, current asset inventory. PCI DSS expects organizations to maintain a current inventory of authorized and unauthorized access points. EASM discovery scans identify externally accessible services and ports that may constitute unintended access points.
- Requirement 11.3 (External and internal vulnerabilities are regularly identified, prioritized, and addressed): This is the most directly applicable requirement. It mandates external vulnerability scanning at least quarterly by an Approved Scanning Vendor (ASV), plus scans after significant changes. EASM provides the continuous scanning layer between ASV engagements, helping demonstrate ongoing diligence and catch new exposures between quarterly cycles.
PCI DSS still requires quarterly ASV scans from an approved vendor. EASM does not replace this obligation. However, continuous EASM scanning between ASV engagements helps demonstrate ongoing vulnerability management and catches new exposures before the next quarterly assessment.
NIS2 Directive: Risk Management, Incident Handling, Supply Chain
The NIS2 Directive (Network and Information Security Directive 2) had a transposition deadline of 17 October 2024, though national implementation has landed at different times across member states. It significantly expands the scope of organizations subject to cybersecurity obligations and introduces specific requirements for risk management measures. Article 21 is the core requirement:
- Risk management measures (Article 21.2a): Organizations must implement risk analysis and information system security policies. This requires knowing what systems are exposed and what risks they carry. EASM provides the external risk assessment data that feeds these policies: discovered assets, open ports, detected vulnerabilities, and risk scores.
- Incident handling (Article 21.2b): NIS2 requires incident prevention, detection, and response capabilities. Drift detection and change monitoring from EASM tools help identify unauthorized changes to the external surface that may indicate incidents or create incident risk. Port monitoring and certificate tracking provide early warning signals.
- Supply chain security (Article 21.2d): Organizations must assess and manage security risks from their supply chain and service providers. EASM can discover third-party services, hosted assets, and vendor-managed infrastructure that form part of your external surface, providing visibility into supply chain exposure.
Some entity types are in scope regardless of size. NIS2 applies to "essential" and "important" entities across 18 sectors, including energy, transport, healthcare, digital infrastructure, ICT service management, and manufacturing. If your organization operates in the EU and employs more than 50 people or has annual revenue above 10 million euros, NIS2 likely applies to you.
SOC 2: Logical Access and System Monitoring
SOC 2 (System and Organization Controls 2) is widely adopted by SaaS vendors and service providers. Two Common Criteria are directly supported by EASM data:
- CC6.1 (Logical and physical access controls): This criterion requires organizations to implement logical access security measures over information assets. EASM helps demonstrate CC6.1 compliance by providing evidence of port monitoring (identifying unexpected open ports), service enumeration (detecting unauthorized services), and continuous inventory of external access points. Drift detection highlights when new access vectors appear without authorization.
- CC7.1 (System monitoring): This criterion requires monitoring of system components to detect anomalies and evaluate events. EASM provides continuous monitoring evidence: scheduled scan results, drift event logs, vulnerability trend data, and alert histories. This data demonstrates that your organization actively monitors its external surface for security-relevant changes.
SOC 2 audits evaluate controls over a period (typically 6-12 months for Type II). EASM tools that maintain historical data across the audit period provide particularly strong evidence, because they show consistent monitoring rather than a single point-in-time snapshot.
Compliance Mapping: EASM Capabilities to Framework Controls
The following table maps specific EASM capabilities to the framework controls they help address. Use this as a reference when preparing audit evidence or assessing which capabilities your EASM program needs to cover.
| EASM Capability | PCI DSS 4.0 | NIS2 | SOC 2 |
|---|---|---|---|
| Asset Discovery | Req 12.5.1 — Maintain a current inventory of in-scope system components | Art 21.2a — Risk analysis requires complete asset visibility | CC6.1 — Inventory of logical access points to information assets |
| Vulnerability Scanning | Req 11.3 — External vulnerability scans; Req 6.3 — Identify and manage vulnerabilities | Art 21.2a — Technical risk assessment and mitigation | CC7.1 — Detect anomalies and evaluate security events |
| Port Monitoring | Req 12.5.1 — Keep the component inventory current; Req 11.3 — Identify exposure changes | Art 21.2b — Incident prevention through change detection | CC6.1 — Monitor and restrict logical access controls |
| Certificate Monitoring | Req 4.2 — Protect cardholder data with strong cryptography in transit | Art 21.2a — Cryptography and encryption policy measures | CC6.1 — Encryption controls over data in transit |
| Drift Detection | Req 11.3 — Scan after significant changes; Req 6.5 — Change control processes | Art 21.2b — Incident detection through unauthorized change identification | CC7.1 — Detect anomalous activity; CC6.1 — Unauthorized access detection |
| Risk Scoring | Req 6.3 — Prioritize vulnerabilities by risk ranking | Art 21.2a — Risk-based approach to security measures | CC7.1 — Evaluate severity of detected events |
| Scheduled Reporting | Req 11.3 — Evidence of regular scan execution and remediation tracking | Art 21.2f — Policies to assess the effectiveness of risk-management measures | CC7.1 — Evidence of continuous monitoring over the audit period |
This mapping shows how EASM capabilities support specific controls. It does not mean that deploying an EASM tool automatically satisfies these requirements. Each framework has additional procedural, organizational, and documentation requirements beyond technical tooling. Your qualified assessor or auditor determines whether controls are adequately implemented.
Using EASM Data as Audit Evidence
Raw scan results are not audit evidence. Auditors need data that is organized, contextualized, and directly tied to the controls being assessed. Here is how to transform EASM output into evidence that auditors can efficiently review.
What to Export
Prepare these data sets before your audit engagement:
- Asset inventory export: A complete list of discovered external assets with their status, classification, and owner. This demonstrates you maintain an accurate, up-to-date inventory of your internet-facing surface (PCI DSS 12.5.1, NIS2 Art 21.2a, SOC 2 CC6.1).
- Vulnerability scan history: Time-stamped records of every scan executed during the audit period, including scan type, coverage, and findings count. This shows continuous monitoring rather than point-in-time testing (PCI DSS 11.3, SOC 2 CC7.1).
- Drift event logs: A chronological record of detected changes to your external surface: new ports, removed services, certificate changes, DNS modifications. This demonstrates active change detection (NIS2 Art 21.2b, SOC 2 CC7.1).
- Risk score trends: Charts showing how your overall risk posture changed over the audit period. Downward trends demonstrate effective remediation. Upward spikes with subsequent resolution demonstrate responsive incident handling.
- Remediation timelines: For each finding, the date discovered, date assigned, date resolved, and current status. This demonstrates your vulnerability management process has defined SLAs and tracks outcomes (PCI DSS 6.3, NIS2 Art 21.2a).
How to Present Evidence to Auditors
Structure your evidence package around the controls being tested, not around the tool that generated the data. Auditors evaluate controls, not products.
- Organize by control, not by feature. Create folders or sections named after specific requirements (e.g., "PCI DSS 11.3 — External Vulnerability Scanning") and place the relevant exports in each.
- Include coverage dates. Every export should clearly state the date range it covers. Auditors need to verify that monitoring was continuous across the entire audit period with no gaps.
- Show the process, not just the data. Include documentation of your scan schedules, escalation procedures, and remediation workflows alongside the raw data. Auditors want to see that the data is part of a managed program.
- Highlight exceptions and their resolution. If there were periods where monitoring lapsed or findings were not remediated within SLA, document why and what compensating controls were in place. Transparency builds auditor confidence.
Assessors typically expect the last four quarterly ASV scan reports; PCI DSS separately requires twelve months of audit log history, with three months immediately available. SOC 2 Type II audits typically cover 6-12 months. NIS2 does not specify a retention period but regulatory practice suggests maintaining records for the duration of your compliance cycle plus one year. Export and archive your EASM data regularly.
What to Do Now: Prepare Compliance Evidence in 4 Steps
Whether your next audit is in three months or next quarter, start building your evidence base now. The longer your historical monitoring data, the stronger your audit position.
Run discovery scans on all domains and IP ranges. Identify every internet-facing asset. Classify each by owner, environment, and criticality. This becomes your baseline asset register for audit evidence.
Review the compliance mapping table above. Identify which controls apply to your organization. For each applicable control, determine what EASM data you need to collect and how frequently.
Set up scheduled vulnerability scans, drift detection, and port monitoring on your critical assets. Ensure scans run frequently enough to demonstrate continuous coverage across your audit period.
Schedule monthly exports of scan results, drift events, and risk score trends. Store them in your compliance documentation repository. When audit time arrives, you will have months of continuous monitoring evidence ready.
How DriftAlarm Supports Compliance Workflows
DriftAlarm is built to help security teams generate the evidence auditors ask for, without manual data collection. Here is how specific platform features map to compliance evidence needs.
Scheduled Scans with Historical Records
DriftAlarm runs discovery, vulnerability, and deep security scans on configurable schedules. Every scan result is time-stamped and stored, building a continuous record across your audit period. You can demonstrate to auditors that monitoring ran consistently with no gaps.
Drift Detection and Alert History
The drift detection engine monitors your external surface for unauthorized changes: new open ports, modified DNS records, certificate expirations, and service configuration shifts. Each drift event is logged with a timestamp, the specific change detected, and the asset affected. This event log directly supports NIS2 incident prevention requirements and SOC 2 CC7.1 system monitoring evidence.
Risk Score Trends and Trend Charts
The Command Center displays risk score trends over time for each asset and your overall surface. These trend charts show whether your security posture is improving, stable, or degrading. Auditors use this type of trend data to assess whether your vulnerability management program is effective over the audit period.
Scan Result Exports
All scan results, asset inventories, and drift events can be exported for inclusion in audit evidence packages. Export data includes timestamps, scan configuration, coverage scope, and detailed findings, formatted for auditor review.
DriftAlarm helps generate evidence and supports compliance workflows. It does not certify compliance with any framework, and DriftAlarm itself does not hold SOC 2, PCI DSS, or NIS2 certification. Compliance determinations are made by your qualified assessor based on your complete control environment.
Frequently Asked Questions
Does EASM satisfy the PCI DSS external vulnerability scanning requirement?
No. PCI DSS requires external vulnerability scans performed by an Approved Scanning Vendor on a quarterly cadence and after significant changes, and an EASM platform is not an ASV engagement. What EASM adds is coverage between those quarterly scans — a current external asset inventory and continuous scan history that shows exposures were being detected, not just assessed four times a year.
Which SOC 2 criteria does external attack surface monitoring support?
Most commonly CC6.1 and CC7.1. CC6.1 covers logical access controls over information assets, where an inventory of externally reachable services and ports is relevant evidence. CC7.1 covers detecting configuration changes that introduce new vulnerabilities — which is exactly what drift detection produces. SOC 2 does not prescribe a specific tool or scan; your auditor evaluates the whole control environment.
Does NIS2 require continuous attack surface monitoring?
Not by name. NIS2 Article 21 requires risk-management measures — risk analysis and security policies, incident handling, supply chain security, and procedures to assess whether those measures work — and leaves the implementation to you. Continuous external monitoring is one reasonable way to evidence the risk-analysis and detection parts. Whether NIS2 applies to you at all depends on your sector and size.
What attack surface evidence should I export before an audit?
Four things, each with an explicit date range: a current inventory of internet-facing assets with owner and classification; a timestamped scan history covering the whole audit period, so there are no visible gaps; a chronological log of detected changes — new ports, DNS edits, certificate changes; and per-finding remediation timelines showing discovered, assigned, and resolved dates. Organize them by control, not by product feature.