Home / Blog
Axipro Resource Hub
Latest Articles
Researchers who buy second-hand drives off online marketplaces keep finding the same thing: live data. A widely cited study by Blancco Technology Group found that 42% of used drives sold on eBay still held recoverable information, including financial records and personal data the previous owners assumed was long gone. The drives were not hacked; they were thrown away by organizations that treated deleting a file as the same thing as destroying it. Secure data disposal is where many compliance programs fail. ISO 27001, SOC 2, and GDPR all demand it, but they describe it in different languages, enforce it through different mechanisms, and punish failure in very different ways. This article sets out what each framework requires, where the requirements overlap, and how to run a single disposal program that satisfies all three at once. Why Secure Data Disposal Matters Across Compliance Frameworks Disposal is the last link in the data lifecycle, and the easiest one to skip. An organization can run flawless access controls, encryption, and monitoring for years and still cause a reportable breach the moment one unwiped laptop leaves the building. A recoverable drive in a recycling skip is functionally identical to an open database on the internet, and auditors and regulators know it. Most disposal failures are unforced errors: a control that was already written into policy but never carried through to the actual hardware. The gap between having a disposal policy and proving this specific drive was destroyed is exactly where audits and breach investigations live. Defining Secure Data Disposal: Key Terms and Concepts What Is Secure Data Disposal? Secure data disposal is the end-to-end process of removing data and the equipment that holds it from active use, in a way that prevents its recovery. It covers the full lifecycle end: deletion of data while a system is still live, sanitisation of media that will be reused, physical destruction of media that will not, and the safe handling of equipment that is recycled, returned to a lessor, or sold. Disposal is the goal. The methods are how you get there. What Is Secure Data Destruction? Secure data destruction is the subset of disposal that renders media permanently unusable or its contents mathematically irretrievable. Shredding a drive, pulverising it, incinerating it, or destroying the encryption keys that make an encrypted disk readable are all forms of destruction. Destruction is one route to disposal, and it is the right route when the data is highly sensitive, or the media will never be reused. Secure Data Disposal vs. Secure Data Destruction: What Is the Difference? The distinction matters more than it looks. Disposal is the outcome you owe to every framework: data gone, unrecoverable, equipment handled appropriately. Destruction is just one of the methods. You can dispose of data without destroying the hardware by sanitising a drive thoroughly enough to reuse it. Confusing the two leads to two classic mistakes: destroying assets that could have been securely wiped and reused, and assuming a quick deletion counts as disposal when it does not. Important: Emptying the recycle bin, formatting a drive, or hitting delete does not dispose of data under any of these frameworks. Standard deletion only removes the pointer to the data; the bits remain until they are overwritten. Every framework discussed here expects the data to be unrecoverable, which is a far higher bar than not visible. What ISO 27001 Requires for Secure Data Disposal ISO/IEC 27001 handles disposal through a small cluster of Annex A controls that auditors read as a single process rather than in isolation. The two controls that do most of the work are 7.14 and 8.10. For a deeper look at how these controls fit into a broader compliance program, see our ISO 27001 implementation guide. ISO 27001 Annex A 7.14: Secure Disposal or Re-Use of Equipment Annex A 7.14 is a physical control. Before any equipment is disposed of or reused, the organisation must check whether it holds information assets or licensed software and ensure those are permanently erased or the media physically destroyed. It applies to servers, laptops, desktops, mobile devices, printers, network gear, and any storage media: if it ever processed information, it is in scope. The control replaces the older 2013 clause 11.2.7 and adds explicit expectations around removing identifying markings and handling end-of-occupancy scenarios. ISO 27001 Control 8.10: Information Deletion Annex A 8.10 is a technological control, and it focuses on the data rather than the box. It requires information stored in systems, devices, or media to be deleted when it is no longer required, and rendered unrecoverable. The cleanest way to keep these straight: 8.10 governs the data while it is in use or reaches its retention limit; 7.14 governs the hardware at end of life. Most retention-driven deletion sits under 8.10; most decommissioning sits under 7.14. ISO 27001 Control 8.12: Data Leakage Prevention and Its Role in Disposal Control 8.12 is rarely filed under disposal, but improperly discarded media is one of the oldest data leakage channels there is. A drive that leaves your control with recoverable data on it is a leak, regardless of how it left. Treating disposal as part of your leakage prevention posture forces the right question at the right time: what could walk out the door on this device, and has it actually been removed? Physical Destruction and Irretrievable Erasure Under ISO 27001 ISO 27001 offers two broad routes: physically destroy media that holds information, or erase and overwrite it so retrieval by a malicious party is precluded. The standard cross-references ISO/IEC 27040 for detailed sanitisation methods. The unifying requirement is that recovery should be impractical, not merely inconvenient. Deletion alone never satisfies this. Overwriting, Full-Disk Encryption, and Other Approved Methods Overwriting user-accessible storage with multiple passes is acceptable for many sensitivity levels. Full-disk encryption changes the economics of disposal entirely: if a device is encrypted from day one and the keys are properly managed, secure disposal can be as simple as destroying the keys, a technique known as
A business continuity plan that has never been tested is, to a SOC 2 auditor, a document and nothing more. The Availability criteria do not award credit for a polished plan sitting in a shared drive. They ask for evidence that you ran the plan, watched it work or fail, recorded what happened, and fixed what broke. That gap — between having a plan and proving it works — is where most availability findings originate. Business continuity plan testing for SOC 2 is the exercise that turns your plan into auditable evidence. It maps directly to Availability criterion A1.3, one of the few SOC 2 controls that explicitly requires you to test something rather than merely document it. This guide covers what counts as a valid test, the test types auditors accept, a step-by-step process, the exact evidence you need, and the mistakes that turn a routine review into a finding. What Is Business Continuity Plan Testing in the Context of SOC 2? Business continuity plan (BCP) testing is the structured validation of whether your organization can keep critical operations running — and restore them within defined targets — during a disruption. In a SOC 2 context, the testing is not freeform. It must produce dated, traceable evidence that the recovery procedures in your plan actually work, that the people involved know their roles, and that systems and data come back within your stated recovery objectives. Why SOC 2 Requires Business Continuity Plan Testing SOC 2 is an attestation against the AICPA’s Trust Services Criteria, and the Availability category exists specifically for organizations that make uptime or resilience commitments to customers. A plan you never exercise cannot demonstrate operating effectiveness over the audit period — which is the entire point of a Type 2 examination. Testing is the control that converts a static plan into a recurring, observable activity an auditor can sample. SOC 2 Trust Services Criteria and BCP Testing Requirements Availability is one of the five Trust Services Criteria, and it is optional, included only when your service commitments warrant it. When in scope, it is built around three sub-criteria: A1.1 addresses capacity management. A1.2 addresses recovery infrastructure and backup processes. A1.3 addresses the testing of recovery procedures. BCP testing lives squarely in A1.3, with A1.2 supplying the backups and infrastructure that the test validates. Availability Criteria A1.2 and A1.3 Explained Per the AICPA’s Trust Services Criteria, A1.2 requires the entity to design, implement, operate, and monitor environmental protections, recovery infrastructure, and data backup processes that meet its availability objectives. In plain terms: you need real backups, stored away from production, with recovery infrastructure ready to use. A1.3 then requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. The two work as a pair: A1.2 builds the capability, A1.3 proves it functions. Important: The most common A1.3 gap is not a missing test. It is a test that never validated the recovery objectives. Teams run a tabletop, write “no issues found,” and move on — but the plan claims a 4-hour RTO that no one ever measured against an actual restore. If your plan states recovery targets, your test evidence must show whether you met them. A test that does not measure against your RTO and RPO leaves the most important question unanswered. What Auditors Look for During a BCP Test Review Auditors want proof that the test happened, proof that it was meaningful, and proof that it led somewhere. Concretely, that means a test plan with a defined scenario, a dated record of execution with participants, results measured against your recovery objectives, a list of gaps or issues found, and evidence that those issues were remediated. A test that finds nothing and changes nothing is treated with suspicion — because real tests almost always surface something. Types of Business Continuity Plan Tests Accepted for SOC 2 SOC 2 does not mandate a specific test type. It expects the rigor of the test to match the criticality of what you are protecting. The four common approaches sit on a spectrum from low-effort, low-disruption to high-effort, high-assurance. Tabletop Exercises A tabletop exercise is a facilitated discussion where key personnel talk through a disruption scenario and their responses. It is cheap, fast, and excellent for confirming that people understand their roles and that the plan reads coherently. Its limit is obvious: nobody actually recovers anything. For many organizations a tabletop is a legitimate annual test, especially in the first audit cycle, but auditors expect more rigor as a program matures. Walkthrough and Simulation Tests A simulation applies a specific scenario and asks the team to perform recovery actions, not just describe them. It is more involved than a tabletop and far better at exposing the gaps that only appear when people touch the tools. Simulations are where teams discover that a runbook references a system that was decommissioned, or that the on-call engineer lacks the access the plan assumes. Full Interruption Tests A full interruption test shuts down primary systems and shifts operations entirely to the recovery environment. It is the most comprehensive validation available and the only one that proves your failover genuinely works end to end. It also carries real operational risk, so it demands thorough planning and is usually reserved for mature programs and the most critical systems. Parallel Testing Parallel testing activates recovery systems alongside production without taking the primary offline, then compares the two to confirm the recovery environment performs as expected. It delivers much of the assurance of a full interruption test while sparing the business the disruption. For most SaaS and cloud-hosted services, parallel testing of failover and restore is the sweet spot between confidence and risk. How to Test Your Business Continuity Plan for SOC 2 Compliance The sequence below aligns with the contingency planning process in NIST’s Contingency Planning Guide, SP 800-34, which auditors widely treat as authoritative for resilience practices. Each step produces an artifact, and the artifacts together form
A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.
HIPAA and GDPR are the two most consequential data protection frameworks any healthcare or technology organisation is likely to encounter. They share a common purpose, protecting sensitive personal data, but they differ significantly in scope, enforcement mechanisms, and compliance obligations. For organisations operating across the Atlantic, understanding where they align, where they clash, and how to satisfy both simultaneously is not optional. It is a legal necessity. What Is HIPAA? The Health Insurance Portability and Accountability Act was enacted by the U.S. Congress in 1996. Its original purpose was to modernise the flow of healthcare information and ensure the portability of health insurance coverage. Over time, it became primarily known for its data protection requirements, administered by the U.S. Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR). HIPAA is built around three core rules. The Privacy Rule governs how Protected Health Information (PHI) may be used and disclosed. The Security Rule sets standards for safeguarding electronic PHI (ePHI). The Breach Notification Rule establishes mandatory reporting timelines when PHI is compromised. Who Needs to Be HIPAA Compliant? HIPAA applies to covered entities, healthcare providers, health plans, and healthcare clearinghouses, and to their business associates: any third-party organisation that handles PHI on their behalf. If you build software that processes patient data for a U.S. hospital, you are a business associate. If you store medical records in the cloud for an insurance company, you are a business associate. A Business Associate Agreement (BAA) is the formal contract that governs this relationship. What Types of Data Does HIPAA Protect? HIPAA protects Protected Health Information (PHI): any individually identifiable information relating to a person’s past, present, or future physical or mental health condition, the provision of healthcare, or the payment for healthcare. This includes names, dates of birth, Social Security numbers, medical record numbers, and any data that could be used to identify a patient in connection with their health. Electronic PHI, the subset stored or transmitted digitally, is subject to the Security Rule’s additional technical requirements. What Is GDPR? The General Data Protection Regulation came into force across the European Union on 25 May 2018, replacing the 1995 Data Protection Directive. It is the world’s most comprehensive data privacy law, and its extraterritorial reach means it extends well beyond Europe’s borders. The GDPR is enforced by national Data Protection Authorities (DPAs) and coordinated at the European level by the European Data Protection Board (EDPB). Unlike HIPAA, GDPR is not sector-specific. It applies to any organisation processing the personal data of EU residents, regardless of industry. Who Needs to Be GDPR Compliant? Any organisation that processes the personal data of individuals located in the European Union, regardless of where the organisation is based. A U.S. hospital treating European patients, a SaaS company offering services to German users, or a health app collecting data from French residents all fall within GDPR’s scope. The regulation applies to both data controllers (organisations that determine how and why data is processed) and data processors (third parties that process data on a controller’s behalf). What Types of Data Does GDPR Protect? GDPR protects all personal data: any information relating to an identified or identifiable natural person. Health data is explicitly designated a special category under GDPR Article 9, commanding heightened protection alongside biometric data, genetic data, racial or ethnic origin, religious beliefs, and sexual orientation. HIPAA vs GDPR: Key Differences at a Glance Feature HIPAA GDPR Jurisdiction United States only EU + extraterritorial reach Sector Healthcare only All sectors Regulatory body HHS / OCR National DPAs / EDPB Data covered PHI only All personal data Consent model Treatment-based exceptions Explicit consent required Breach notification 60 days (proposed: 72 hours) 72 hours Max fine $1.9M per violation category/year €20M or 4% of global turnover DPO required No Sometimes Right to erasure Limited Yes Scope and Geographic Reach HIPAA’s reach is defined by entity type: it applies to covered entities and business associates operating within the United States. Whether a patient holds EU citizenship is irrelevant to HIPAA jurisdiction. What matters is whether the organisation providing care or processing health data operates within the U.S. healthcare system. GDPR’s reach is defined by the location of the data subject, not the organisation. Article 3 of the GDPR gives it explicit extraterritorial effect. If your organisation targets or monitors EU residents, GDPR applies, regardless of where you are headquartered, where your servers are located, or what industry you operate in. Types of Data Protected: Personal Data vs Protected Health Information (PHI) This is the sharpest structural difference between the two frameworks. HIPAA is focused exclusively on health data in the context of healthcare delivery or payment. GDPR covers all personal data, from email addresses and IP addresses to medical records and genetic profiles. Health data under GDPR is a subset of the broader personal data category, not the totality of it. An organisation that is fully HIPAA-compliant may still be in violation of GDPR if it mishandles employee data, marketing data, or website analytics. Legal Basis for Data Processing GDPR requires organisations to identify a valid legal basis before processing any personal data. For health data, that typically means explicit consent or one of the specific derogations in Article 9(2), such as processing necessary for medical diagnosis or the provision of healthcare. This is a meaningful threshold; pre-ticked boxes, bundled consent, or vague terms of service do not meet GDPR’s standard. HIPAA takes a different approach. It permits covered entities to use and disclose PHI for treatment, payment, and healthcare operations without obtaining patient consent. Authorisation is required only in specific circumstances, such as disclosures for marketing purposes or release of psychotherapy notes. Important: GDPR’s explicit consent requirement creates real friction for U.S. healthcare organisations treating EU patients. A hospital cannot rely on its standard HIPAA-compliant intake forms to satisfy GDPR. The legal bases must be documented separately, and consent forms must meet the GDPR’s granularity requirements. Regulatory Authority and Enforcement HHS OCR is
31% of organizations have caught former employees accessing SaaS applications after their departure (source). Seventy percent of intellectual property theft happens in the ninety days surrounding a resignation announcement. The pattern is so consistent that auditors now treat termination day as one of the highest-risk windows on the security calendar. This article is a working employee offboarding checklist for IT, security, and HR teams who want to close that window cleanly. It walks through ten steps that revoke access without leaving gaps, then covers edge cases (remote workers, hostile exits, lost devices), the manual-versus-automation tradeoff, and post-offboarding monitoring. Use it as a baseline and adapt it to your environment. What Is Employee Offboarding and Why Does Access Revocation Matter? Employee offboarding is the structured process of separating a person from an organization: removing their access, recovering company property, documenting their exit, and updating records. The access revocation piece is the part where most programs fail quietly. Accounts get disabled in the identity provider but stay active in a dozen SaaS tools. Badges get collected but VPN tokens stay valid. The person is gone; the keys to the building are not. Why Employee Offboarding Is a Critical Security Risk Offboarding fails because access has multiplied faster than the processes designed to manage it. The average enterprise now operates somewhere between 275 and 660 SaaS applications depending on size, with employees touching dozens of them each week. Each application is a separate place that needs to be cleaned up, and each one creates an independent point of failure. The departing employee is a particularly acute version of this risk because the motivation to walk away with something often peaks during the same window that access is supposed to be revoked. The Cost of Leaving Access Open After Departure The financial picture is well documented. The 2025 Ponemon Cost of Insider Risks report puts the average annual cost of insider-related incidents at $17.4 million per organization, with containment taking an average of 81 days. Even when a departed employee never actively misuses their access, the existence of a forgotten account is enough to compromise a SOC 2 audit, trigger a breach notification, or create the credentialed beachhead that an outside attacker eventually exploits. The cases keep appearing. Cash App was breached in 2022 when a former employee accessed the records of 8 million customers after leaving. In May 2024, FinWise Bank disclosed that a former employee accessed internal systems after departure because access had never been fully revoked. Intel sued a former engineer in 2024 for downloading roughly 18,000 sensitive files in the days before he left. Ponemon’s 2025 report found that containment costs scale steeply with time. Incidents resolved in under 30 days averaged about $11 million, while those over 90 days averaged $17 million. The biggest variable is not detection capability. It is how fast access actually came down on day one. Compliance and Legal Implications of Incomplete Offboarding Access revocation is not a “best practice.” It is an explicit control requirement in nearly every framework against which an organization is likely to be audited. NIST SP 800-53 control PS-4 requires that on termination, organizations disable system access within an organization-defined time period, terminate or revoke any authenticators, and retrieve organizational property. ISO/IEC 27001 includes equivalent expectations under its Annex A controls for termination of employment. The AICPA Trust Services Criteria for SOC 2 cover this under Common Criteria CC6.2 and CC6.3, and auditors routinely pull a sample of terminated employees and verify timestamps in the identity provider against the HR system. GDPR adds a separate dimension. If a former employee still has access to the personal data of EU residents, that constitutes unauthorised processing under Article 32, and it is the controller’s responsibility, regardless of intent. HIPAA does the same for protected health information. Whatever the framework, the question an auditor or regulator will ask is the same: how quickly was access revoked, and can you prove it? Who Is Responsible for Employee Offboarding? Offboarding fails most often because no one owns the whole process. Four groups need to be in the loop, and each one has a distinct job. HR and People Operations HR is the source of truth for the termination event. Their job is to capture notice of departure, set the official last day, communicate timing to the rest of the business, and serve as the trigger that starts every downstream task. If HR does not record the termination in the HRIS, nothing automated will fire. IT and Security Teams IT executes the access teardown. They disable accounts in the identity provider, revoke SSO and OAuth tokens, remove SaaS application access, suspend email, and recover devices. Security teams typically run the audit trail and post-offboarding monitoring, and they are the ones answering when an account flagged six months later turns out to belong to a person who left in March. Legal and Compliance Legal handles NDA reminders, IP assignment confirmations, non-disclosure obligations, and any contractual surprises. Compliance owns the documentation: the evidence trail that proves the offboarding actually happened and met the relevant control requirements. For regulated industries this becomes audit evidence; for everyone else it becomes legal cover. Direct Managers Managers know things HR does not. They know which shared drives the person owned, which third-party vendors they had standing access to, which client passwords they may have rotated themselves, and which projects need a transition plan. A solid offboarding process forces the manager into the workflow with a checklist of role-specific items, because no central team can guess them. Employee Offboarding Checklist: 10 Steps to Revoke Access Without Leaving Gaps This is the core sequence. The order matters: starting with notification and inventory before disabling accounts means you do not lock the person out of a system you still need them to hand off. Step 1: Initiate Offboarding Immediately Upon Notice of Departure The moment notice is given — resignation, termination decision, or end of contract — the offboarding workflow should start. This means
The Drata Agent is the part of Drata’s compliance stack that actually touches employee devices. It is a lightweight, read-only desktop application that runs in the system toolbar, reads a narrow set of security configuration settings, and reports them back to the Drata platform on a daily schedule. If a SOC 2 or ISO 27001 audit depends on showing that every endpoint has disk encryption, screen lock, antivirus, a password manager, and automatic updates enabled, the Agent is the thing that produces that evidence. This guide covers exactly what it does, how it works, how to install it on macOS, Windows, and Linux, and what to do when it stops syncing. What Is the Drata Agent? The Drata Agent is a desktop application built with Electron, the same framework used by Slack, VS Code, and Discord. It uses osquery, an open-source endpoint instrumentation tool created at Facebook and now maintained as a Linux Foundation project, to query the operating system for specific configuration values. The Agent runs from the system toolbar — the menu bar on macOS, the system tray on Windows, and the indicator area on Linux — and synchronises once per day with Drata’s backend. The full source code of the Agent has been open source since June 2023. Anyone can audit the code on Drata’s GitHub organisation, including security teams that need to validate it before deploying to the fleet. The Agent supports the latest two major versions of each operating system. On macOS, that currently means macOS 26 (Tahoe) and macOS 15 (Sequoia), with Agent version 3.9.0 or higher. On Windows, it covers the two most recent stable versions Microsoft actively maintains. On Linux, only LTS distributions are supported; Ubuntu 22.04 LTS and 24.04 LTS are the current supported targets. What the Drata Agent Does (and Does Not Do) The Agent collects a tightly scoped list of configuration data points — specifically the items that map to typical SOC 2 and ISO 27001 device-level controls. The Agent does read: disk encryption status (FileVault, BitLocker, LUKS); screen lock and screensaver configuration; installed antivirus or endpoint protection software; installed password manager applications; operating system version and update status; the list of installed applications and browser extensions for Chrome, Firefox, and Internet Explorer (used to detect AV and password manager presence); and the operating system identifier and machine serial number for asset attribution. The Agent does not read keystrokes, browsing history, file contents, clipboard data, screen contents, network traffic, or any application data. Access is strictly read-only at the system-preferences level. The Agent cannot make changes to the device, push configuration, or remediate failed controls. If a check fails, the employee or IT team fixes it manually; the Agent simply observes whether the fix worked on the next sync. Important: Read-only does not mean invisible. The Agent enumerates installed applications and browser extensions to detect antivirus and password manager presence, and this list is sent to Drata. If that level of visibility is a concern for privacy or works council requirements, address it before rollout — not after. How Does the Drata Agent Work? Once installed and registered, the Agent runs continuously in the background. It performs scheduled checks, reports results to Drata, and updates itself when new versions ship. Synchronization Process The Agent syncs once per day. The sync runs at the first opportunity each calendar day: typically, the first network connection after the device was off or asleep, the moment the user logs in if the Agent autostarts, or any manual trigger from the toolbar menu. The data sent is small — a structured report of the configuration values the Agent read, plus the Agent version and machine identifier. There is no telemetry of user activity. When the sync succeeds, the device’s compliance status in Drata updates within a few minutes. When it fails, the device may show an Unable to get data status, and the corresponding controls in Drata will appear unconfirmed until the next successful sync. Automatic Updates The Agent updates itself. When a new version is released, the Agent shows a notification asking the user to allow the update. Updates are mandatory — running an outdated Agent eventually causes registration and sync failures. Linux installations through Ubuntu’s package manager auto-update via the system updater starting with version 3.6; AppImage installations and Arch AUR builds need to be updated manually or through the AUR helper. Prerequisites Before Installing the Drata Agent Before installation, three things need to be in place. First, the device user needs an active Drata account with employee onboarding tasks assigned. Second, the operating system must be a supported version. Third, the user needs administrator rights on the device to install the application, since it registers a startup item. The user will also need access to their work email during installation. Registration uses a magic-link verification flow, and the verification email arrives within a minute of clicking Register Drata Agent in the Drata UI. How to Install the Drata Agent on Mac There are two practical paths on macOS: install through Homebrew Cask, or download the signed installer directly from MyDrata. Installation via Homebrew The Drata Agent is published as an official cask in the Homebrew repository, which is the cleanest install method for engineers who already use Homebrew for package management. The cask requires macOS 12 (Monterey) or newer. The install command is: brew install –cask drata-agent After Homebrew finishes, open Drata Agent.app from /Applications, then return to MyDrata and click Register Drata Agent. A magic-link email arrives shortly after. Open the link, copy the token portion of the URL, paste it into the Agent’s register dialog, and confirm. Run or Build the Drata Agent on Mac For organisations that want to build from source rather than use the published package, the GitHub repository contains the full Electron build pipeline. Build prerequisites include Node.js and electron-builder, and the osquery binaries need to be supplied separately. Drata explicitly notes that locally built packages are not signed and that production registration requires an
Most SOC 2 auditors will pick a handful of recent hires from your employee list and request one specific artifact: the completed background check, dated before the start date, sourced from a documented vendor. If you cannot produce it, that is an exception in your report. The control sits inside CC1.4, the Common Criteria provision the AICPA derives from COSO Principle 4, and it is one of the most reliably tested items in a first-year SOC 2 examination. Background screening is not the most technically complex part of SOC 2. It is, however, one of the most procedurally fragile. The policy looks simple on paper. Then a contractor starts a week early because someone needed help shipping a release, the vendor screening gets postponed, and a year later an auditor finds the gap in twenty minutes. This guide explains what SOC 2 actually requires when it comes to background checks, what auditors look for in practice, and how to build a screening programme that holds up under sampling. What Is a SOC 2 Background Check? A SOC 2 background check is the pre-employment screening a service organisation performs to verify that the people it hires can be trusted with access to systems and data inside the SOC 2 scope. It is the operational evidence that supports the abstract principle baked into the Trust Services Criteria: the organisation hires competent people of sound integrity, and it can prove it. In practice, that means a documented check performed by a third party that returns verified information about identity, criminal history, employment history, and, depending on the role, education and credit. The check is run against every new hire before they get logical or physical access to systems within scope. The result is stored, mapped to a named employee, and retrievable on demand. It is worth being clear on one thing: SOC 2 does not prescribe what a background check must contain. The AICPA criteria describe outcomes, not procedures. Your policy is what defines what gets checked, on whom, and how often. The auditor then tests whether you followed your own policy. Why SOC 2 Background Checks Are Important Insider risk is one of the few attack vectors that perimeter security cannot fix. An employee or contractor with legitimate credentials and undisclosed motives sits inside the network from day one. Background checks are how mature security programmes reduce the probability of that scenario before it begins. According to the Verizon 2024 Data Breach Investigations Report, insider threats continue to represent a persistent and costly category of security incidents, reinforcing why personnel vetting remains a foundational control. Auditors care for a related reason. The Control Environment criteria (CC1) sit at the top of the SOC 2 framework because everything else rests on the assumption that the people running the controls are competent and trustworthy. Skip the screening step, and the rest of the audit is built on a weaker foundation. That is why background check evidence is one of the first things auditors sample, and why a missing or late check shows up as an exception even when the rest of your control environment is strong. Insider Note: Auditors do not just check that the screening happened. They check the timing. A background check completed two months into employment is often treated the same as no check at all, because access to in-scope systems was granted before the control was operative. Time stamps matter as much as the document. SOC 2 Background Check Requirements Which Trust Service Criteria Require Background Checks? Background checks are explicitly referenced in the Common Criteria that apply to every SOC 2 engagement, regardless of which optional Trust Services Categories you include. The two controls that matter most are CC1.1 and CC1.4. CC1.1 establishes the entity’s commitment to integrity and ethical values. Background checks support this by demonstrating due diligence in selecting people who meet the organisation’s standards of conduct. CC1.4 is more direct: it derives from COSO Principle 4, which states that the entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. Within CC1.4, evaluating individual backgrounds is named as a specific point of focus. That is the hook auditors use. Because these are Common Criteria, they apply regardless of whether you are scoping Security only or adding Availability, Confidentiality, Processing Integrity, or Privacy. There is no version of SOC 2 that escapes them. Who Needs to Be Background Checked for SOC 2? The short answer: anyone whose role gives them logical or physical access to systems, data, or facilities within your SOC 2 scope. The longer answer requires you to draw the line in your own policy and stick to it. At a minimum, this includes full-time employees who join the organisation after the policy is in place. Most mature programmes extend the requirement to part-time employees, contractors who receive credentials, and outsourced personnel performing in-scope work. Vendors are usually handled differently — through contractual flow-down requirements rather than direct screening — but the principle is the same: people inside the trust boundary must be vetted. Roles with privileged access (engineers with production credentials, finance staff with payment system rights, support personnel handling customer data) often warrant deeper screening than baseline roles. Documenting this risk-based approach in your policy is good practice and helps you defend the design of your control during the audit. What Types of Checks Must Be Performed? The Trust Services Criteria do not specify which checks to run. That decision sits with the organisation, informed by role, jurisdiction, and regulatory context. A common baseline for SOC 2 purposes covers several distinct areas. Identity verification confirms the candidate is who they claim to be. Criminal history — national, state, or county-level depending on jurisdiction — flags relevant offences. Employment verification confirms the work history disclosed during hiring. Education verification matters for roles where credentials are material. For positions touching finance, payments, or fiduciary responsibility, a credit check may be appropriate. For roles with global reach, a global
The AICPA never wrote the words penetration test required into SOC 2. Yet a service organization that walks into a Type II audit without one is almost guaranteed to leave with findings, follow-up questions, or a delayed report. That gap, between what the standard technically demands and what auditors operationally expect, is where most companies trip. This article breaks down the real SOC 2 penetration testing requirements: where they sit in the Trust Services Criteria, what auditors look for during Type I and Type II engagements, how often you should test, and what a good pen test report needs to contain to satisfy your auditor without inflating your budget. Understanding SOC 2 and Its Security Expectations What Is SOC 2? SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that handle customer data. Unlike a certification, SOC 2 is an opinion: a licensed CPA firm reviews your security controls and issues a report stating whether those controls are designed (Type I) or operating (Type II) effectively. SOC 2 reports are read by enterprise procurement teams, security reviewers, and risk officers. Most B2B SaaS contracts in 2026 require one before signing. What Controls Does SOC 2 Require? Rather than dictating specific technologies, SOC 2 requires that you design and operate controls that demonstrably meet each criterion under the Trust Services Criteria (TSC). That gives you flexibility, and it also gives auditors latitude to ask hard questions. Does SOC 2 Require Penetration Testing? The Official SOC 2 Position on Penetration Testing The phrase penetration test appears in the AICPA’s 2017 Trust Services Criteria publication (with 2022 revisions) inside a single Point of Focus under CC7.1, the Common Criterion that requires entities to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. The Point of Focus suggests management uses a variety of ongoing and separate risk and control evaluations to determine whether controls function. Penetration testing is named as one option. That is the entire textual basis. There is no clause that mandates an annual external pentest, no specification of scope, no required methodology. Short Answer: There Are No Mandatory SOC 2 Pen Test Requirements You can technically obtain a SOC 2 report without a penetration test, provided you can show your auditor that you use alternative evaluations to satisfy CC4.1 (ongoing monitoring) and CC7.1 (vulnerability identification). In practice, almost nobody does this successfully. Long Answer: You Still Need SOC 2 Penetration Testing Auditors view penetration testing as the strongest available evidence that your controls work against a determined adversary, not just on paper. CC4.1 asks the entity to perform ongoing monitoring to ascertain whether internal controls are present and functioning; a pen test is the most direct way to evaluate that. CC6.1 asks whether logical access controls can be bypassed; a pen test answers that question directly. CC7.1 ties this together by requiring you to detect newly introduced vulnerabilities. If you skip pen testing, you carry the burden of proving your alternative evidence is at least as good. That is a steeper hill than most organizations realize. What Auditors Expect During Type I and Type II Engagements A SOC 2 Type I report assesses control design at a single point in time. A Type II report assesses operating effectiveness over a defined audit period, typically six to twelve months. Both increasingly assume a recent penetration test exists. For Type II especially, auditors expect the test to fall within the audit window, with documented remediation of any critical or high findings before the period closes. Auditors rarely refuse a Type II report over a missing pentest outright, but they will issue a finding or qualified opinion if they cannot validate CC4.1 evidence. That qualification will be read by every customer reviewing your report. Most CISOs would rather budget $15,000 for a pentest than try to explain a qualified opinion to a procurement team. What Are the Actual SOC 2 Penetration Testing Requirements? Alignment with Trust Services Criteria A pen test that supports a SOC 2 audit must map its findings to specific criteria. Most reputable pentest firms now produce a Trust Services Criteria mapping appendix that ties identified vulnerabilities back to CC4.1, CC6.1, CC7.1, and where relevant CC7.2 through CC7.4. Without that mapping, your auditor has to do the interpretive work themselves, which typically means a follow-up request and a slower report. Scope Definition Requirements Scope should match your SOC 2 system boundary, not your entire infrastructure. If your audit covers a single SaaS product, its API, and its AWS account, that is what should be tested. Auditors look for evidence that the pen test scope was derived from the system description in your SOC 2 report. A mismatch between the two is one of the most common causes of fieldwork delays. Testing Frequency and Timing Requirements SOC 2 does not specify a frequency. Annual testing has become the de facto standard, with additional testing after material changes to architecture, authentication, or hosting. For organizations on continuous deployment, some auditors now accept a combination of annual deep-dive testing and continuous automated assessment as sufficient coverage, but this should be confirmed with your auditor before you rely on it. Remediation Evidence Requirements Findings without remediation are findings against you. Auditors expect documented remediation plans for every critical and high-severity issue, with closed tickets, retest results, or compensating controls recorded before the audit period ends. A finding sitting open in a backlog at audit time is treated almost identically to a finding that was never addressed. Penetration Testing vs. Vulnerability Scans for SOC 2 Both belong in your control set, but they answer fundamentally different questions. Vulnerability scanning is automated and broad, it identifies known CVEs and misconfigurations across your environment quickly and consistently. Penetration testing is manual and adversarial, it simulates what a real attacker would do with the access and information they can obtain. CC7.1 explicitly references both, and your auditor
The CMMC program turned from advisory framework to binding contract requirement on November 10, 2025, when the DoD’s Title 48 acquisition rule took effect. That single date changed the market for CMMC advisory services overnight, and the Cyber AB Registered Practitioner credential moved from a useful business card to a genuine signal of competence. Over 80,000 companies in the Defense Industrial Base now need help interpreting the rule, and the RP is the formal entry-level role in the ecosystem authorized to provide it. This guide explains what a CMMC Registered Practitioner is, how the role fits alongside CCPs, CCAs, RPOs, and C3PAOs, what it takes to earn the designation, and how Organizations Seeking Certification (OSCs) should think about engaging one. What Is a CMMC Registered Practitioner (RP)? A CMMC Registered Practitioner is an individual authorized by the Cyber AB, the official accreditation body for the CMMC ecosystem, to provide non-certified advisory and consulting services to Organizations Seeking Certification. RPs help defense contractors interpret the CMMC model, scope their environments, build documentation, remediate gaps against NIST SP 800-171, and prepare for the formal assessment they will eventually undergo. The credential exists because the CMMC framework is genuinely dense. CMMC Level 2 maps to all 110 controls in NIST SP 800-171, and Level 3 layers on 24 selected requirements from NIST SP 800-172. Most contractors do not have the in-house expertise to implement these controls cleanly, and the Cyber AB needed a way to identify advisors who had at least demonstrated baseline knowledge of the program. An RP does not perform official assessments. That work is reserved for Certified CMMC Assessors (CCAs) operating under a C3PAO. The RP role is strictly advisory, and the Code of Professional Conduct that every RP must sign makes the boundary explicit. How RPs Fit Into the Broader CMMC Ecosystem The Cyber AB structures the ecosystem into two distinct lanes: consulting and implementation on one side, assessment and certification on the other. RPs sit on the consulting side. CCPs, CCAs, and C3PAOs sit on the assessment side. The two are kept deliberately separate so that no firm can audit work it helped configure, a separation that preserves the integrity of the certification process. Registered Practitioners vs. Certified CMMC Professionals (CCPs) The CCP is a more rigorous credential. CCP candidates must complete formal Cyber AB training delivered by a Licensed Training Provider, pass a commercial background check, and sit a proctored exam administered by CAICO. CCPs can participate in actual assessments as part of a C3PAO assessment team, though they cannot lead them. RPs cannot participate in assessments at all. In practical terms, the RP credential is the right starting point for consultants, MSPs, and internal compliance staff who want to demonstrate baseline CMMC fluency. The CCP is the right credential for professionals planning a career in CMMC assessment work. Registered Practitioners vs. C3PAOs A C3PAO (Certified Third-Party Assessment Organization) is the entity authorized to conduct official Level 2 certification assessments and issue formal CMMC status determinations. Fewer than 100 firms held C3PAO authorization as of early 2026, serving an ecosystem of more than 80,000 contractors. C3PAOs are companies. RPs are individuals. They do completely different jobs: the RP prepares the contractor, the C3PAO certifies them. Important: A C3PAO that helps a client implement controls is barred from later assessing that same client. This is a hard line in the Code of Professional Conduct. If you engage a firm for both readiness and certification work, you will end up paying two different organizations regardless, so plan accordingly from the start. What Does a CMMC Registered Practitioner Do? The work of an RP is the work of getting an organization to the starting line of a formal assessment without surprises. That includes interpreting which CMMC level applies to a given contract, scoping the CUI and FCI environments, identifying gaps against NIST SP 800-171, drafting the System Security Plan (SSP) and Plan of Action and Milestones (POA&M), advising on technical remediation, and coaching the OSC through mock assessments before the real one. Who Can a CMMC RP Help? RPs serve any organization in the Defense Industrial Base that needs to achieve a CMMC status. That includes prime contractors, subcontractors at any tier, MSPs, and MSSPs that handle CUI on behalf of defense clients, manufacturers, research universities, and civilian agency contractors whose departments have adopted CMMC-aligned clauses. The flow-down requirements in 32 CFR §170.23 mean that even small subcontractors who process Federal Contract Information (FCI) must hit Level 1, which keeps RP work relevant well past the first wave of large primes. What Services Does a CMMC RP Provide? The core service menu looks consistent across the market: gap assessments against NIST SP 800-171, scope definition, SSP and POA&M drafting, policy and procedure development, technical advisory on encryption, access control and incident response, and pre-assessment readiness reviews. Strong RPs also help clients interpret recent guidance changes, manage their SPRS score, and prepare evidence packages that will survive scrutiny from a C3PAO assessment team. Pro Tip: Evaluating a Registered Practitioner When evaluating an RP, ask whether they have walked a client through a full C3PAO assessment cycle, not just a gap assessment. There is a significant difference between consultants who write SSPs and consultants who have watched assessors actually challenge one. How to Become a CMMC Registered Practitioner The path is straightforward but not trivial. The Cyber AB controls the registration process end-to-end, and every step must be completed in order. Step 1: Complete the Required CMMC Registered Practitioner Training The RP training is delivered online through the Cyber AB’s learning management system. It covers the CMMC model document, the structure of the ecosystem, scoping methodology, FCI and CUI definitions, prime and subcontractor information flow, the assessment process, and the relationship between CMMC and existing DFARS clauses. The course typically takes around eight hours. Candidates should plan for roughly $500 to $600 in combined training and annual registration costs. Step 2: Register with the Cyber AB After training, candidates submit a
A single VS Code extension installed by a single GitHub employee has cost the world’s largest code host roughly 3,800 of its internal repositories. GitHub confirmed the breach in a five-post thread on X on May 20, 2026, attributing the compromise to a poisoned extension that ran on the employee’s machine and gave attackers a foothold inside Microsoft’s flagship developer platform. The threat group TeamPCP, already infamous for a string of supply chain attacks across npm, PyPI, and PHP packages earlier this year, has claimed responsibility on underground forums and is reportedly asking more than $50,000 for the stolen dataset. GitHub’s own assessment is that the attacker’s claim of around 3,800 exfiltrated repositories is directionally consistent with what investigators have found so far. The company says no customer data was touched. What GitHub Disclosed GitHub broke the news in a numbered thread of five short posts on X, with no entry on the official github.blog or githubstatus.com at the time of disclosure. The company said it detected the compromise of an employee device the previous day, removed the malicious extension version from the marketplace, isolated the affected endpoint, and rotated critical secrets overnight, prioritizing the highest-impact credentials first. “Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only,” GitHub wrote, adding that it would continue to monitor logs for follow-on activity and publish a fuller report once the investigation is complete. The phrasing is careful. Saying GitHub-internal repositories only rules out customer repos, enterprise tenants, and organization data hosted on the public platform, but it leaves open what was inside those 3,800 repos: deployment scripts, infrastructure configuration, API documentation, staging credentials, and the architectural blueprints of GitHub itself. Important Note “No customer data” does not mean “no customer risk.” Internal repositories at a platform like GitHub typically contain deployment topology, secret rotation logic, CI workflows, and references to third-party integrations. Even if no customer secrets are inside, the architectural knowledge alone meaningfully reduces the cost of attacking customers downstream. The Attack: A Trojanized Extension Inside a Trusted Marketplace GitHub has not yet named the specific extension. Security researchers tracking TeamPCP’s tradecraft note that the group has spent 2026 weaponizing exactly this surface, planting trojanized code in package registries and development tools that developers trust by default. The mechanism is brutally simple. A developer browses the VS Code Marketplace, installs an extension that looks legitimate, and grants it the same execution privileges as any other process running under their account. From there, the malware can read source files, exfiltrate Git credentials, harvest tokens from ~/.aws, ~/.kube, and password managers, and clone every repository the developer has access to. There is no permission model meaningfully limiting what an extension can do once it executes. A theme can do anything a debugger can do. Browser extensions get treated as a security boundary. IDE extensions, which see your source code, your credentials, and your terminal, do not. That asymmetry is the single largest unaddressed risk in the modern developer toolchain, and the GitHub incident is the most expensive demonstration of it to date. What GitHub Has Done, and What Comes Next The containment steps GitHub described are textbook: detect, isolate, rotate, monitor. The company says it removed the malicious extension version, took the developer’s machine off the network, and rotated the credentials most likely to provide further pivots. The investigation continues, and GitHub has committed to publishing a fuller report later. Where the response is less defensible is in disclosure. Announcing a breach of this scale exclusively on X, a platform that requires a login to view most posts, drew sharp criticism. As of publication, there is no entry on the GitHub Blog and no advisory on the official status page. Customers governed by frameworks such as DORA or NIS2, both of which have hard supplier-incident notification timelines, will be looking for something more substantive than a Twitter thread. Pro Tip: IDE plugins and Cyber Security Treat any IDE plugin like a piece of production software. Pin to specific versions, disable auto-updates on critical machines, restrict the allowed publisher list (in VS Code via the extensions.allowed setting), and ensure that any project containing credentials cannot be opened by an editor that auto-runs .vscode/tasks.json without confirmation. If you maintain CI/CD secrets, assume that any developer machine with both source access and an unverified extension installed is already in the threat model. For organizations downstream of GitHub itself, the immediate hygiene items are clear. Rotate any GitHub personal access tokens or OIDC credentials that were used in conjunction with packages from the TanStack, UiPath, Mistral AI, OpenSearch, or Guardrails AI namespaces during the early May window. Audit .vscode/ and .claude/ directories for files such as router_runtime.js or setup.mjs. Search for the gh-token-monitor daemon, which acts as a dead-man switch and triggers a destructive rm -rf on token revocation if not removed first. An Incident or a Pattern? GitHub has had a rough quarter on availability, with multiple outages drawing public complaints. A confirmed source-code breach by the most prolific supply chain threat actor of 2026 lands at the worst possible moment for that narrative. Independent agencies such as the Cybersecurity and Infrastructure Security Agency and NIST, through its Secure Software Development Framework, have been warning for years that developer tooling and build pipelines are the soft underbelly of every modern company, and the Wikipedia entry for supply chain attack now reads like a chronological list of escalating incidents. The deeper lesson from the GitHub breach is not that one employee made a mistake. It is that the security model of the modern developer workstation has not kept pace with the value of what sits on it. Until IDE extensions are sandboxed with explicit capability grants, until source code repositories are treated as sensitive assets rather than collaboration surfaces, and until the disclosure norms for breaches at platform-level vendors are tightened, the Mini Shai-Hulud playbook will continue to work. GitHub will not be the last victim of this campaign. It is simply, for
Plenty of companies treat an ISO 27001 certificate as proof of GDPR compliance. It is not. The two frameworks overlap heavily, but they answer different questions, and the gap between them is exactly where regulators tend to look. ISO 27001 tells you how to build a defensible security program. GDPR tells you what the law expects when that program touches personal data. Run one without understanding the other, and you will either over-engineer security you do not strictly need, or miss privacy obligations that carry real financial exposure. This article maps where ISO 27001 and GDPR meet, where they part ways, and how to run them as a single coordinated effort rather than two competing projects. What Is ISO 27001? ISO/IEC 27001 is the international standard for an Information Security Management System, or ISMS. The current edition is ISO 27001:2022. It is not a checklist of technical fixes. It is a management framework: a structured, repeatable way to identify information security risks, decide how to treat them, document those decisions, and improve over time. Clauses 4 to 10 of the standard define the mandatory ISMS requirements, covering leadership, risk assessment, internal audit, and management review. Annex A then lists 93 controls grouped into four themes: organisational, people, physical, and technological. You do not implement all 93 by default. You select the controls that address your assessed risks and justify your choices in a document called the Statement of Applicability. Certification against ISO 27001 is voluntary and is granted by an accredited third-party body after an audit. What Is GDPR? The General Data Protection Regulation is European Union law. It has been applied since 25 May 2018, and it applies to any organisation that processes the personal data of people in the EU, wherever that organisation is based. GDPR is fundamentally about the rights of individuals, not just the security of data. It grants people rights over their personal data, including access, correction, erasure and portability. It places obligations on the organisations that decide how data is used (controllers) and those that process it on their behalf (processors). It requires a lawful basis for every processing activity, mandates breach notification, and demands transparency about what happens to people’s information. You do not implement GDPR and receive a certificate. You obey it, and a regulator decides whether you have. Key Differences Between ISO 27001 and GDPR Scope and Purpose ISO 27001 protects all information assets an organisation holds: intellectual property, financial records, operational data, source code and, yes, personal data. Its purpose is the confidentiality, integrity and availability of information in general. GDPR is narrower in one sense and broader in another. It covers only personal data of individuals in the EU, but it protects the person behind the data, not merely the data itself. A system can be flawlessly secure and still violate GDPR. Legal Obligation vs. Voluntary Certification This is the difference that catches people out. GDPR is binding law. If you process EU personal data, compliance is not optional, and there is no opting out. ISO 27001 is a voluntary standard. Organisations pursue it for assurance, for competitive advantage, and because customers increasingly demand it. Crucially, there is no such thing as a GDPR certificate. Regulators assess compliance through investigation and enforcement, not through a badge you can display. Penalties for Non-Compliance GDPR fines run on two tiers under Article 83. Less severe infringements — such as failures around records of processing or breach notification — can reach €10 million or 2% of global annual turnover, whichever is higher. The more serious tier, covering breaches of the core processing principles and data subject rights, can reach €20 million or 4% of global annual turnover. Failing an ISO 27001 audit carries no legal fine at all. The consequence is commercial: you do not get the certificate, or you lose it, and that can cost you contracts. How ISO 27001 and GDPR Align Despite their different purposes, the two frameworks were built on compatible logic, which is why running them together works. Both treat information security as central. GDPR Article 32 requires “appropriate technical and organisational measures” to secure personal data. That phrasing is almost a direct description of what an ISO 27001 ISMS produces. The controls an organisation selects for confidentiality and access already serve the regulation’s security expectations. Both are risk-based. ISO 27001 starts every control decision from a risk assessment. GDPR expects the same proportionality: the measures you apply should match the sensitivity of the data and the likelihood and severity of harm. One risk methodology can serve both, provided you assess personal data processing risks alongside broader security risks. Both demand incident response. ISO 27001’s incident management controls require organisations to detect, assess and respond to security events. GDPR Article 33 requires notifying the supervisory authority of a personal data breach within 72 hours of becoming aware of it. The ISO process is the engine that makes the GDPR deadline achievable. How ISO 27001 Can Help You Comply With GDPR Four areas of an ISMS do direct, practical work toward GDPR compliance. Asset management. ISO 27001 requires an inventory of information and associated assets, with owners assigned. You cannot protect personal data, respond to access requests, or maintain records of processing if you do not know where that data lives. The asset inventory is the foundation for both frameworks. Access control. Identity management, privileged access controls and the principle of least privilege limit who can see personal data. That directly supports the GDPR requirement to ensure confidentiality and to prevent unauthorised access. Operational security. Logging, malware protection, backup and secure configuration keep personal data accurate, available and resistant to compromise. These map cleanly onto the integrity and availability expectations in Article 32. Techniques such as data masking for GDPR and ISO 27001 also sit within this space, reducing exposure without sacrificing operational utility. Incident management. A defined process for detecting and handling security events gives you the evidence trail and the response capability you need to
A company that already holds a SOC 2 report has, by most industry estimates, already built somewhere between 60 and 80 percent of what ISO 27001 certification requires. Yet only a small fraction of organizations actually capture that overlap. Teams run the second framework as a fresh project, rewrite policies that already exist, and re-collect evidence they already have on file. The result is paying twice for the same security program. SOC 2 to ISO 27001 mapping is the discipline that stops this. It is a control crosswalk: a structured comparison that shows which SOC 2 controls already satisfy which ISO 27001 requirements, where the genuine gaps sit, and what new work the second framework actually demands. Done well, it turns the second audit from a rebuild into a mapping exercise. What Is SOC 2 to ISO 27001 Mapping? SOC 2 to ISO 27001 mapping links each SOC 2 Trust Services Criterion to its corresponding ISO 27001 clause or Annex A control. The output is a single control library: each control is defined once, tagged to both frameworks, and backed by evidence that both auditors will accept. Worth being clear about upfront: a crosswalk does not make you compliant with anything. It shows where coverage already exists and where it does not. The real work still sits in control design, evidence discipline, and keeping the mapping current as systems and vendors change. A spreadsheet built once and never touched again becomes an audit liability, not an asset. For a structured starting point, a thorough SOC 2 to ISO 27001 gap analysis will surface those liabilities before an auditor does. SOC 2 Trust Services Criteria: An Overview SOC 2 is an attestation framework from the American Institute of Certified Public Accountants (AICPA). It is built on five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category, and every SOC 2 report includes it. The Security category is evaluated through the Common Criteria, written as CC1 through CC9, containing 32 individual criteria in total. CC1 through CC5 cover the control environment, communication, risk assessment, monitoring, and control activities, and they align directly with the COSO internal control framework. CC6 through CC9 are more technology-specific, covering logical and physical access, system operations, change management, and risk mitigation. A SOC 2 audit produces one of two report types. A Type 1 report assesses control design at a single point in time. A Type 2 report assesses both design and operating effectiveness across an observation window, usually 3 to 12 months. A licensed CPA firm issues the report. SOC 2 is an attestation, not a certification, and there is no such thing as a SOC 2 certificate. ISO 27001 Annex A Controls: An Overview ISO/IEC 27001 is the international standard for an information security management system, or ISMS. The current version, ISO 27001:2022, has two distinct layers, and the distinction matters for any mapping effort. Clauses 4 through 10 define the management system itself: organizational context, leadership, planning, risk treatment, support, operations, performance evaluation, and improvement. These clauses are mandatory. Annex A is the second layer, a reference catalogue of 93 controls grouped into four themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). The 2022 revision consolidated the previous 114 controls and 14 domains and added 11 new controls covering areas such as threat intelligence and cloud security. Annex A controls are not all mandatory. Organizations select controls based on a risk assessment and record their choices, including any exclusions and the reasoning behind them, in a Statement of Applicability. Certification is granted by an accredited body, lasts three years, and requires annual surveillance audits. Learn more about what the full certification process involves. Key Structural Differences That Affect Mapping The two frameworks share a large security foundation, but they are built differently, and a mapping that ignores the structural gaps will fail. Understanding ISO 27001 vs SOC 2 at a structural level is the prerequisite for any mapping work worth doing. Four differences matter most. ISO 27001 certifies a management system, while SOC 2 attests to a set of controls. ISO Clauses 4 through 10 have no direct SOC 2 equivalent, because SOC 2 never asks you to prove you run a continuous, governed program; it asks only whether specific controls met specific criteria during the review period. Scope differs too. An ISO 27001 ISMS is expected to cover the organization broadly, while SOC 2 scope is set at the level of a system or service. The outputs differ as well: ISO produces a pass or fail certificate, whereas a SOC 2 report can carry noted exceptions or a qualified opinion and still be a valid, useful report. And because SOC 2 Type 2 tests evidence across a defined window, a control that worked only on audit day will not pass. The most common mapping mistake is treating ISO 27001 as SOC 2 plus a few extra controls. It is not. The Annex A controls map cleanly, but the ISMS management clauses, including internal audit, management review, and continual improvement, are a separate body of work with no SOC 2 starting point. Budget for them as net-new. SOC 2 Common Criteria to ISO 27001 Control Mapping The Common Criteria map to ISO 27001 with a high degree of overlap. The table below is a practical starting crosswalk for the CC series. It lists the primary ISO 27001 references rather than every possible match, and your auditor’s judgment will shape the final mapping. SOC 2 Common Criteria Topic Primary ISO 27001:2022 References CC1 Control Environment Clauses 5 (Leadership), 6 (Planning), A.5.1, A.5.2, A.6.1–A.6.4 CC2 Communication and Information Clause 7.4 (Communication), A.5.1, A.6.3, A.8.2 CC3 Risk Assessment Clause 6.1 (Risk Assessment), A.5.7, A.8.8 CC4 Monitoring Activities Clause 9 (Performance Evaluation), A.5.35, A.5.36, A.8.16 CC5 Control Activities Clause 6.1.3 (Risk Treatment), A.5.37, A.8.9 CC6 Logical and Physical Access A.5.15–A.5.18, A.5.31, A.7.1–A.7.4, A.8.2–A.8.5, A.8.18 CC7 System Operations and Incident Response A.5.24–A.5.28, A.8.15, A.8.16 CC8
The world’s first comprehensive AI law is not a single switch that flips on in August 2026. It is a layered regulation that has been activating in stages since February 2025. As of May 2026, it is already being rewritten to give companies more time on the hardest parts. Anyone trying to plan around a single deadline is working from a map that no longer matches the territory. The law’s reach is also global. Just as GDPR exported European privacy norms worldwide, the EU AI Act is producing a Brussels Effect for artificial intelligence: a regulation drafted in Europe that becomes the de facto global standard. Companies in the US, the UK, Bahrain, and anywhere else with EU customers or EU-facing outputs are already in scope, whether or not they have a European office. This guide cuts through the noise. It explains what the EU AI Act actually requires, who it applies to, which rules are already live, which were just pushed back by the EU’s recent simplification deal, and what the penalties really look like for companies of different sizes. What Is the EU AI Act? The EU AI Act (Regulation (EU) 2024/1689) is a horizontal law that sets harmonised rules for developing, placing on the market, and using artificial intelligence systems across the European Union. It is the first comprehensive AI law passed by any major regulator anywhere in the world, and it entered into force on 1 August 2024. The Act takes a risk-based approach. Rather than regulating AI as a single category, it sorts AI systems into tiers based on the harm they could cause to health, safety, or fundamental rights. The higher the risk, the stricter the obligations. Prohibited uses are banned outright. High-risk uses are heavily regulated. Most everyday AI — like spam filters and product recommenders — is left alone. The law also creates a separate, parallel regime for general-purpose AI (GPAI) models, the foundation models behind systems like ChatGPT, Claude, and Gemini. That regime is enforced at the EU level rather than at the national level. Why Was the EU AI Act Created? The official answer is to foster trustworthy AI in Europe. The real answer is broader: the EU watched generative AI go mainstream in late 2022 and concluded that existing law — particularly GDPR — was not enough to address the specific risks AI systems pose. Opacity in decision-making, bias in hiring tools, biometric surveillance, and the manipulation potential of generative models all sat uneasily in the regulatory gap between data protection law and product safety law. The EU’s stated goals are to protect health, safety, and fundamental rights, while preserving innovation and the single market. The political subtext is the Brussels Effect: do for AI what GDPR did for privacy, and let European rules become the global default by virtue of market access. Brazil, Canada, the UK, several US states, and Gulf jurisdictions, including Bahrain, are already drafting AI rules that borrow heavily from the EU framework. For a broader view of how AI governance is likely to evolve through the end of the decade, the trajectory is already becoming clear. Who Does the EU AI Act Apply To? The Act does not apply to AI itself. It applies to people and organisations that build, sell, or use AI systems. Article 3 defines those roles without reference to company size, so a two-person startup is in scope on the same legal basis as a Fortune 500 enterprise. Providers and Developers A provider is anyone who develops an AI system — or has one developed — and places it on the EU market or puts it into service under their own name or trademark. Providers carry the heaviest load of obligations, particularly for high-risk systems: risk management, technical documentation, conformity assessment, post-market monitoring, and incident reporting. A provider is distinct from a downstream developer who simply integrates a third-party AI component. But the line moves: if you take a general-purpose model and put your name on the resulting product, you can become a provider yourself. Deployers and Operators A deployer is anyone using an AI system in a professional capacity. If you are a bank running a credit-scoring model you bought from a vendor, you are a deployer. Deployers have lighter obligations than providers but still carry real ones: ensuring human oversight, monitoring system behaviour, informing affected individuals, and conducting fundamental rights impact assessments where required. The term operator in the Act is an umbrella that covers providers, deployers, importers, distributors, and authorised representatives. Application Outside the EU This is where many non-EU companies get caught. The AI Act applies extraterritorially. A US LLC training a model in Texas, a UK firm running an AI hiring tool, or a Bahrain-based fintech using AI for credit scoring is in scope the moment the output affects someone in the EU. If a US company develops an AI hiring tool and a German employer uses it on German candidates, the US provider is in scope — even with no EU office. The trigger is whether the system’s output is used in the Union, not where the company sits. Pro Tip: Selling AI tools to EU customers outside the EU. If you sell AI tools to EU customers from outside the EU, you must appoint an authorised representative established in a Member State before placing high-risk systems on the market. This is not optional and is one of the most commonly missed obligations for non-EU providers. The Risk-Based Approach: How the EU AI Act Classifies AI Systems The framework sorts AI systems into four tiers. The obligations scale with the tier. Unacceptable Risk: Prohibited AI Practices Article 5 prohibits eight categories of AI practice outright. These prohibitions became enforceable on 2 February 2025, well before the rest of the Act. The banned practices are: Subliminal or manipulative techniques are designed to distort behaviour and cause significant harm. Exploitation of vulnerabilities related to age or disability. Social scoring by public or private actors —
Phase 1 of the Cybersecurity Maturity Model Certification program went live on November 10, 2025. From that date, the Department of Defense can write CMMC requirements directly into new solicitations, and contractors who handle even basic government data cannot win awards without a current CMMC status in the Supplier Performance Risk System (SPRS). For roughly 63 percent of the Defense Industrial Base, that means Level 1: 15 foundational safeguards, an annual self-assessment, and a signed affirmation from a senior official. Level 1 is the smallest version of CMMC. It is also the one most contractors are about to encounter first, and the one with the highest false-confidence rate. This guide covers every requirement, every assessment objective, and every step from scoping to SPRS submission. What Is CMMC Level 1? CMMC Level 1 (Foundational) is the entry tier of the Cybersecurity Maturity Model Certification program, codified in 32 CFR Part 170. It requires defense contractors who handle Federal Contract Information (FCI) to implement 15 basic safeguarding practices and to confirm that implementation through an annual self-assessment. The 15 practices come directly from FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, a clause that has technically applied to federal contractors since 2016. What CMMC added is an assessment methodology and a verification mechanism. Until CMMC, no one was checking whether contractors actually did the 15 things they were contractually obligated to do. Under the final CMMC Program Rule, effective December 16, 2024, that gap is closed. Earlier CMMC drafts described Level 1 as a 17-practice framework because three physical-protection requirements were listed separately. The final rule consolidates them, and the official count now sits at 15 practices with 17 underlying assessment objectives drawn from NIST SP 800-171A. Both numbers are correct, depending on which level of granularity you are working at. What Is the Purpose of CMMC Level 1? The purpose is narrow and specific: to protect FCI from unauthorized disclosure. FCI is information the federal government either generates or receives during contract performance that is not intended for public release. Think proposal correspondence, delivery schedules, performance reports, and routine contract communications. None of it is classified. None of it is even particularly sensitive in the traditional sense. But aggregated across thousands of contractors and exposed to adversaries, it gives a meaningful picture of what the U.S. government is buying, from whom, and on what timeline. Level 1 exists because too much of the Defense Industrial Base was failing to apply even basic hygiene to that data. CMMC Level 1 turns inconsistent expectations into a yearly verification cycle. CMMC Level 1 Scope The CMMC Assessment Scope for Level 1 is defined in the official DoD CMMC Level 1 Scoping Guide. It covers every information system that processes, stores, or transmits FCI, along with the people, processes, and physical facilities that interact with those systems. In practical terms, scope includes workstations and servers that handle FCI, cloud services used to store or transmit FCI, email systems used to send or receive FCI, file-sharing platforms holding FCI documents, network infrastructure carrying FCI traffic, physical facilities where any of the above are located, and personnel with access to any of the above. Anything that does not touch FCI is out of scope. This is the simplest scoping model in CMMC, and it is also where most contractors trip up. The temptation is to declare a narrow scope (“just the one folder on the file server”) and ignore the email, the laptops, and the backups. Auditors and primes will not accept it. CMMC Level 1 Requirements: All 15 Practices Explained The 15 practices fall across six domains. Each is mapped to a NIST SP 800-171 control identifier, but Level 1 only assesses the subset of objectives relevant to FCI. Access Control (AC) AC.L1-B.1.I – Authorized Access Control Practice: Limit information system access to authorized users, processes acting on behalf of authorized users, or devices. Maintain a current list of users, processes, and devices authorized to access systems holding FCI. This means active user-account management: unique identifiers for each user, accounts disabled promptly when employment ends, and a documented process for reviewing who has access and why. Shared credentials are not acceptable. This is the foundation every other access control practice is built on, and it is where many contractors have their first reckoning with how loosely their environments have actually been managed. AC.L1-B.1.II – Transaction and Function Control Practice: Limit information system access to the types of transactions and functions that authorized users are permitted to execute. Apply the principle of least privilege. A user with access to read FCI does not automatically get access to delete it, share it externally, or modify system configurations. Role-based access controls (RBAC) satisfy this requirement. In practice, this means auditing what each role can actually do in your systems and trimming permissions down to what is genuinely necessary for the job function. AC.L1-B.1.III – External Connections Practice: Verify and control or limit connections to and use of external information systems. Know what external systems your in-scope environment connects to — cloud storage, partner networks, contractor laptops on home Wi-Fi — and apply controls to those connections. Acceptable Use Policies, VPN requirements, and explicit allow-lists for external sharing all map here. The key word is verify: you need documented evidence that external connections are inventoried and controlled, not just assumed to be fine. AC.L1-B.1.IV – Control Public Information Practice: Control information posted or processed on publicly accessible information systems. Make sure FCI does not end up on your public website, your company blog, or any other publicly accessible system. This is mostly a process control: establish who is allowed to publish to public-facing systems and what review happens before anything goes live. It sounds obvious, but incidents involving inadvertent FCI disclosure through company websites and public repositories are more common than the industry likes to admit. Identification and Authentication (IA) IA.L1-B.1.V – Identification Practice: Identify information system users, processes acting on behalf of users, or devices. Every user,
Risk analysis failures sit behind 76% of HIPAA enforcement actions in 2025, according to The HIPAA Journal’s annual breach report. That single statistic explains why healthcare organizations and their business associates are rethinking how they manage HIPAA. Its no longer enough to conduct an annual policy review, it is now a continuous control problem. Drata fits that shift. It is a security and compliance automation platform that connects to the systems where PHI lives, maps controls to the HIPAA Privacy, Security, and Breach Notification Rules, and keeps evidence current between formal assessments. This guide covers what Drata actually does for HIPAA: which rules it addresses, how the automation works in practice, what it leaves to humans, and how readiness compares to running parallel frameworks like SOC 2. What Is HIPAA and Why Does Compliance Matter? The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is the U.S. federal law governing the protection of protected health information (PHI). It applies to two categories of organizations: covered entities (health plans, healthcare clearinghouses, and most providers) and business associates, a category that captures any vendor, SaaS company, or service provider that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Enforcement is led by the HHS Office for Civil Rights (OCR). Penalties scale with culpability, capped at roughly $2.1 million per violation category per year after inflation adjustments. OCR’s 2025 enforcement priorities were almost entirely focused on the Security Rule, particularly the requirement to conduct a thorough, organization-wide risk analysis. The agency has confirmed that 2026 will follow the same playbook, with risk management evidence (proof that identified risks are being actively reduced) becoming a separate focus area in its own right. Healthcare also remains the most expensive sector for breaches. IBM’s 2024 Cost of a Data Breach Report put the average healthcare breach at $9.48 million, more than double the cross-industry average. The cost is not abstract: in 2025, OCR penalties for risk analysis failures ranged from $25,000 against small practices up to $3 million against a national medical supplier following a phishing-driven breach. What Is Drata and How Does It Support HIPAA Compliance? Drata is a GRC automation platform that integrates with cloud infrastructure, identity providers, HRIS systems, ticketing tools, and endpoint management to continuously collect evidence and test controls against more than 30 compliance frameworks. HIPAA was added in late 2021 as Drata’s third framework, joining SOC 2 and ISO 27001. For HIPAA specifically, Drata does not certify anyone; there is no formal HIPAA certification anyway, but it operationalizes the work that OCR expects to see when an investigation lands. That includes mapped controls for administrative, physical, and technical safeguards; policy templates for HIPAA-specific requirements like the Business Associate Agreement; embedded workforce training; an integrated risk management module; and an evidence library that auditors and counsel can access during a review. Worth Knowing: There is no government-issued HIPAA certification. Any vendor claiming to make you “HIPAA certified” is using marketing language. What auditors and OCR investigators actually look for is documented, ongoing compliance with the three HIPAA Rules. Drata’s value sits in producing that documentation continuously rather than retroactively. For a deeper look at what formal certification actually involves in adjacent frameworks, see our guide to HIPAA certification. Key HIPAA Requirements Drata Helps You Address HIPAA consists of three operative rules, each with distinct compliance obligations. Drata’s control library maps to all three. HIPAA Privacy Rule The Privacy Rule governs the use and disclosure of PHI in any form: electronic, paper, or verbal. It defines 18 specific identifiers that constitute PHI, sets the minimum necessary standard, and gives patients rights of access, amendment, and accounting of disclosures. Drata supports this through policy templates (notice of privacy practices, minimum necessary use, patient rights procedures), access tracking through integrations with identity providers, and workforce training that covers permissible uses and disclosures. HIPAA Security Rule The Security Rule is where most enforcement activity happens. It applies specifically to electronic PHI (ePHI) and requires three categories of safeguards: administrative, physical, and technical. According to HHS, the Security Rule “requires implementation of appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information.” Drata’s control library maps directly to the 45 CFR Part 164 implementation specifications, both required and addressable. HIPAA Breach Notification Rule The Breach Notification Rule requires notification to affected individuals, HHS, and, for breaches affecting 500 or more residents of a state, the media, no later than 60 days after discovery. Drata supports breach response through incident management workflows, policy templates that codify the four-factor risk assessment, and audit trails for breach documentation. The platform does not file your OCR breach report for you; that remains a human task, but it keeps the underlying evidence organized. Important: OCR has explicitly stated that breach notification failures were the second most common reason for a financial penalty in 2025. More than one-fifth of enforcement actions included a breach notification violation. The 60-day clock starts at discovery, not at confirmation, so detection latency directly increases legal exposure. How Drata Automates HIPAA Compliance Automation in Drata operates on four layers: evidence collection, control monitoring, gap detection, and integration with healthcare-relevant tools. The combination is what produces the continuous compliance posture that OCR is now effectively demanding through its risk management initiative. Automated Evidence Collection for HIPAA Audits Drata reports that its platform automates roughly 80% of evidence collection across frameworks. For HIPAA, that means pulling configuration data from AWS, Azure, or GCP; enrollment status from MDM tools like Jamf or Intune; SSO and MFA enforcement from Okta or Entra ID; and onboarding/offboarding records from HRIS platforms. Instead of screenshotting these on demand for an auditor, the platform timestamps and stores them on a continuous basis. Real-Time HIPAA Compliance Monitoring The platform runs automated tests against connected systems daily. If MFA is disabled on an administrator account that has access to a system holding ePHI, the relevant control flips to failing status and the owner
Compliance Hubs
Discover key insights, educational articles, helpful guides and more.
Researchers who buy second-hand drives off online marketplaces keep finding the same thing: live data. A widely cited study by Blancco Technology Group found that 42% of used drives sold on eBay still held recoverable information, including financial records and personal data the previous owners assumed was long gone. The drives were not hacked; they were thrown away by organizations that treated deleting a file as the same thing as destroying it. Secure data disposal is where many compliance programs fail. ISO 27001, SOC 2, and GDPR all demand it, but they describe it in different languages, enforce it through different mechanisms, and punish failure in very different ways. This article sets out what each framework requires, where the requirements overlap, and how to run a single disposal program that satisfies all three at once. Why Secure Data Disposal Matters Across Compliance Frameworks Disposal is the last link in the data lifecycle, and the easiest one to skip. An organization can run flawless access controls, encryption, and monitoring for years and still cause a reportable breach the moment one unwiped laptop leaves the building. A recoverable drive in a recycling skip is functionally identical to an open database on the internet, and auditors and regulators know it. Most disposal failures are unforced errors: a control that was already written into policy but never carried through to the actual hardware. The gap between having a disposal policy and proving this specific drive was destroyed is exactly where audits and breach investigations live. Defining Secure Data Disposal: Key Terms and Concepts What Is Secure Data Disposal? Secure data disposal is the end-to-end process of removing data and the equipment that holds it from active use, in a way that prevents its recovery. It covers the full lifecycle end: deletion of data while a system is still live, sanitisation of media that will be reused, physical destruction of media that will not, and the safe handling of equipment that is recycled, returned to a lessor, or sold. Disposal is the goal. The methods are how you get there. What Is Secure Data Destruction? Secure data destruction is the subset of disposal that renders media permanently unusable or its contents mathematically irretrievable. Shredding a drive, pulverising it, incinerating it, or destroying the encryption keys that make an encrypted disk readable are all forms of destruction. Destruction is one route to disposal, and it is the right route when the data is highly sensitive, or the media will never be reused. Secure Data Disposal vs. Secure Data Destruction: What Is the Difference? The distinction matters more than it looks. Disposal is the outcome you owe to every framework: data gone, unrecoverable, equipment handled appropriately. Destruction is just one of the methods. You can dispose of data without destroying the hardware by sanitising a drive thoroughly enough to reuse it. Confusing the two leads to two classic mistakes: destroying assets that could have been securely wiped and reused, and assuming a quick deletion counts as disposal when it does not. Important: Emptying the recycle bin, formatting a drive, or hitting delete does not dispose of data under any of these frameworks. Standard deletion only removes the pointer to the data; the bits remain until they are overwritten. Every framework discussed here expects the data to be unrecoverable, which is a far higher bar than not visible. What ISO 27001 Requires for Secure Data Disposal ISO/IEC 27001 handles disposal through a small cluster of Annex A controls that auditors read as a single process rather than in isolation. The two controls that do most of the work are 7.14 and 8.10. For a deeper look at how these controls fit into a broader compliance program, see our ISO 27001 implementation guide. ISO 27001 Annex A 7.14: Secure Disposal or Re-Use of Equipment Annex A 7.14 is a physical control. Before any equipment is disposed of or reused, the organisation must check whether it holds information assets or licensed software and ensure those are permanently erased or the media physically destroyed. It applies to servers, laptops, desktops, mobile devices, printers, network gear, and any storage media: if it ever processed information, it is in scope. The control replaces the older 2013 clause 11.2.7 and adds explicit expectations around removing identifying markings and handling end-of-occupancy scenarios. ISO 27001 Control 8.10: Information Deletion Annex A 8.10 is a technological control, and it focuses on the data rather than the box. It requires information stored in systems, devices, or media to be deleted when it is no longer required, and rendered unrecoverable. The cleanest way to keep these straight: 8.10 governs the data while it is in use or reaches its retention limit; 7.14 governs the hardware at end of life. Most retention-driven deletion sits under 8.10; most decommissioning sits under 7.14. ISO 27001 Control 8.12: Data Leakage Prevention and Its Role in Disposal Control 8.12 is rarely filed under disposal, but improperly discarded media is one of the oldest data leakage channels there is. A drive that leaves your control with recoverable data on it is a leak, regardless of how it left. Treating disposal as part of your leakage prevention posture forces the right question at the right time: what could walk out the door on this device, and has it actually been removed? Physical Destruction and Irretrievable Erasure Under ISO 27001 ISO 27001 offers two broad routes: physically destroy media that holds information, or erase and overwrite it so retrieval by a malicious party is precluded. The standard cross-references ISO/IEC 27040 for detailed sanitisation methods. The unifying requirement is that recovery should be impractical, not merely inconvenient. Deletion alone never satisfies this. Overwriting, Full-Disk Encryption, and Other Approved Methods Overwriting user-accessible storage with multiple passes is acceptable for many sensitivity levels. Full-disk encryption changes the economics of disposal entirely: if a device is encrypted from day one and the keys are properly managed, secure disposal can be as simple as destroying the keys, a technique known as
A business continuity plan that has never been tested is, to a SOC 2 auditor, a document and nothing more. The Availability criteria do not award credit for a polished plan sitting in a shared drive. They ask for evidence that you ran the plan, watched it work or fail, recorded what happened, and fixed what broke. That gap — between having a plan and proving it works — is where most availability findings originate. Business continuity plan testing for SOC 2 is the exercise that turns your plan into auditable evidence. It maps directly to Availability criterion A1.3, one of the few SOC 2 controls that explicitly requires you to test something rather than merely document it. This guide covers what counts as a valid test, the test types auditors accept, a step-by-step process, the exact evidence you need, and the mistakes that turn a routine review into a finding. What Is Business Continuity Plan Testing in the Context of SOC 2? Business continuity plan (BCP) testing is the structured validation of whether your organization can keep critical operations running — and restore them within defined targets — during a disruption. In a SOC 2 context, the testing is not freeform. It must produce dated, traceable evidence that the recovery procedures in your plan actually work, that the people involved know their roles, and that systems and data come back within your stated recovery objectives. Why SOC 2 Requires Business Continuity Plan Testing SOC 2 is an attestation against the AICPA’s Trust Services Criteria, and the Availability category exists specifically for organizations that make uptime or resilience commitments to customers. A plan you never exercise cannot demonstrate operating effectiveness over the audit period — which is the entire point of a Type 2 examination. Testing is the control that converts a static plan into a recurring, observable activity an auditor can sample. SOC 2 Trust Services Criteria and BCP Testing Requirements Availability is one of the five Trust Services Criteria, and it is optional, included only when your service commitments warrant it. When in scope, it is built around three sub-criteria: A1.1 addresses capacity management. A1.2 addresses recovery infrastructure and backup processes. A1.3 addresses the testing of recovery procedures. BCP testing lives squarely in A1.3, with A1.2 supplying the backups and infrastructure that the test validates. Availability Criteria A1.2 and A1.3 Explained Per the AICPA’s Trust Services Criteria, A1.2 requires the entity to design, implement, operate, and monitor environmental protections, recovery infrastructure, and data backup processes that meet its availability objectives. In plain terms: you need real backups, stored away from production, with recovery infrastructure ready to use. A1.3 then requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. The two work as a pair: A1.2 builds the capability, A1.3 proves it functions. Important: The most common A1.3 gap is not a missing test. It is a test that never validated the recovery objectives. Teams run a tabletop, write “no issues found,” and move on — but the plan claims a 4-hour RTO that no one ever measured against an actual restore. If your plan states recovery targets, your test evidence must show whether you met them. A test that does not measure against your RTO and RPO leaves the most important question unanswered. What Auditors Look for During a BCP Test Review Auditors want proof that the test happened, proof that it was meaningful, and proof that it led somewhere. Concretely, that means a test plan with a defined scenario, a dated record of execution with participants, results measured against your recovery objectives, a list of gaps or issues found, and evidence that those issues were remediated. A test that finds nothing and changes nothing is treated with suspicion — because real tests almost always surface something. Types of Business Continuity Plan Tests Accepted for SOC 2 SOC 2 does not mandate a specific test type. It expects the rigor of the test to match the criticality of what you are protecting. The four common approaches sit on a spectrum from low-effort, low-disruption to high-effort, high-assurance. Tabletop Exercises A tabletop exercise is a facilitated discussion where key personnel talk through a disruption scenario and their responses. It is cheap, fast, and excellent for confirming that people understand their roles and that the plan reads coherently. Its limit is obvious: nobody actually recovers anything. For many organizations a tabletop is a legitimate annual test, especially in the first audit cycle, but auditors expect more rigor as a program matures. Walkthrough and Simulation Tests A simulation applies a specific scenario and asks the team to perform recovery actions, not just describe them. It is more involved than a tabletop and far better at exposing the gaps that only appear when people touch the tools. Simulations are where teams discover that a runbook references a system that was decommissioned, or that the on-call engineer lacks the access the plan assumes. Full Interruption Tests A full interruption test shuts down primary systems and shifts operations entirely to the recovery environment. It is the most comprehensive validation available and the only one that proves your failover genuinely works end to end. It also carries real operational risk, so it demands thorough planning and is usually reserved for mature programs and the most critical systems. Parallel Testing Parallel testing activates recovery systems alongside production without taking the primary offline, then compares the two to confirm the recovery environment performs as expected. It delivers much of the assurance of a full interruption test while sparing the business the disruption. For most SaaS and cloud-hosted services, parallel testing of failover and restore is the sweet spot between confidence and risk. How to Test Your Business Continuity Plan for SOC 2 Compliance The sequence below aligns with the contingency planning process in NIST’s Contingency Planning Guide, SP 800-34, which auditors widely treat as authoritative for resilience practices. Each step produces an artifact, and the artifacts together form
A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.
Guides and Reports
Researchers who buy second-hand drives off online marketplaces keep finding the same thing: live data. A widely cited study by Blancco Technology Group found that 42% of used drives sold on eBay still held recoverable information, including financial records and personal data the previous owners assumed was long gone. The drives were not hacked; they were thrown away by organizations that treated deleting a file as the same thing as destroying it. Secure data disposal is where many compliance programs fail. ISO 27001, SOC 2, and GDPR all demand it, but they describe it in different languages, enforce it through different mechanisms, and punish failure in very different ways. This article sets out what each framework requires, where the requirements overlap, and how to run a single disposal program that satisfies all three at once. Why Secure Data Disposal Matters Across Compliance Frameworks Disposal is the last link in the data lifecycle, and the easiest one to skip. An organization can run flawless access controls, encryption, and monitoring for years and still cause a reportable breach the moment one unwiped laptop leaves the building. A recoverable drive in a recycling skip is functionally identical to an open database on the internet, and auditors and regulators know it. Most disposal failures are unforced errors: a control that was already written into policy but never carried through to the actual hardware. The gap between having a disposal policy and proving this specific drive was destroyed is exactly where audits and breach investigations live. Defining Secure Data Disposal: Key Terms and Concepts What Is Secure Data Disposal? Secure data disposal is the end-to-end process of removing data and the equipment that holds it from active use, in a way that prevents its recovery. It covers the full lifecycle end: deletion of data while a system is still live, sanitisation of media that will be reused, physical destruction of media that will not, and the safe handling of equipment that is recycled, returned to a lessor, or sold. Disposal is the goal. The methods are how you get there. What Is Secure Data Destruction? Secure data destruction is the subset of disposal that renders media permanently unusable or its contents mathematically irretrievable. Shredding a drive, pulverising it, incinerating it, or destroying the encryption keys that make an encrypted disk readable are all forms of destruction. Destruction is one route to disposal, and it is the right route when the data is highly sensitive, or the media will never be reused. Secure Data Disposal vs. Secure Data Destruction: What Is the Difference? The distinction matters more than it looks. Disposal is the outcome you owe to every framework: data gone, unrecoverable, equipment handled appropriately. Destruction is just one of the methods. You can dispose of data without destroying the hardware by sanitising a drive thoroughly enough to reuse it. Confusing the two leads to two classic mistakes: destroying assets that could have been securely wiped and reused, and assuming a quick deletion counts as disposal when it does not. Important: Emptying the recycle bin, formatting a drive, or hitting delete does not dispose of data under any of these frameworks. Standard deletion only removes the pointer to the data; the bits remain until they are overwritten. Every framework discussed here expects the data to be unrecoverable, which is a far higher bar than not visible. What ISO 27001 Requires for Secure Data Disposal ISO/IEC 27001 handles disposal through a small cluster of Annex A controls that auditors read as a single process rather than in isolation. The two controls that do most of the work are 7.14 and 8.10. For a deeper look at how these controls fit into a broader compliance program, see our ISO 27001 implementation guide. ISO 27001 Annex A 7.14: Secure Disposal or Re-Use of Equipment Annex A 7.14 is a physical control. Before any equipment is disposed of or reused, the organisation must check whether it holds information assets or licensed software and ensure those are permanently erased or the media physically destroyed. It applies to servers, laptops, desktops, mobile devices, printers, network gear, and any storage media: if it ever processed information, it is in scope. The control replaces the older 2013 clause 11.2.7 and adds explicit expectations around removing identifying markings and handling end-of-occupancy scenarios. ISO 27001 Control 8.10: Information Deletion Annex A 8.10 is a technological control, and it focuses on the data rather than the box. It requires information stored in systems, devices, or media to be deleted when it is no longer required, and rendered unrecoverable. The cleanest way to keep these straight: 8.10 governs the data while it is in use or reaches its retention limit; 7.14 governs the hardware at end of life. Most retention-driven deletion sits under 8.10; most decommissioning sits under 7.14. ISO 27001 Control 8.12: Data Leakage Prevention and Its Role in Disposal Control 8.12 is rarely filed under disposal, but improperly discarded media is one of the oldest data leakage channels there is. A drive that leaves your control with recoverable data on it is a leak, regardless of how it left. Treating disposal as part of your leakage prevention posture forces the right question at the right time: what could walk out the door on this device, and has it actually been removed? Physical Destruction and Irretrievable Erasure Under ISO 27001 ISO 27001 offers two broad routes: physically destroy media that holds information, or erase and overwrite it so retrieval by a malicious party is precluded. The standard cross-references ISO/IEC 27040 for detailed sanitisation methods. The unifying requirement is that recovery should be impractical, not merely inconvenient. Deletion alone never satisfies this. Overwriting, Full-Disk Encryption, and Other Approved Methods Overwriting user-accessible storage with multiple passes is acceptable for many sensitivity levels. Full-disk encryption changes the economics of disposal entirely: if a device is encrypted from day one and the keys are properly managed, secure disposal can be as simple as destroying the keys, a technique known as
A business continuity plan that has never been tested is, to a SOC 2 auditor, a document and nothing more. The Availability criteria do not award credit for a polished plan sitting in a shared drive. They ask for evidence that you ran the plan, watched it work or fail, recorded what happened, and fixed what broke. That gap — between having a plan and proving it works — is where most availability findings originate. Business continuity plan testing for SOC 2 is the exercise that turns your plan into auditable evidence. It maps directly to Availability criterion A1.3, one of the few SOC 2 controls that explicitly requires you to test something rather than merely document it. This guide covers what counts as a valid test, the test types auditors accept, a step-by-step process, the exact evidence you need, and the mistakes that turn a routine review into a finding. What Is Business Continuity Plan Testing in the Context of SOC 2? Business continuity plan (BCP) testing is the structured validation of whether your organization can keep critical operations running — and restore them within defined targets — during a disruption. In a SOC 2 context, the testing is not freeform. It must produce dated, traceable evidence that the recovery procedures in your plan actually work, that the people involved know their roles, and that systems and data come back within your stated recovery objectives. Why SOC 2 Requires Business Continuity Plan Testing SOC 2 is an attestation against the AICPA’s Trust Services Criteria, and the Availability category exists specifically for organizations that make uptime or resilience commitments to customers. A plan you never exercise cannot demonstrate operating effectiveness over the audit period — which is the entire point of a Type 2 examination. Testing is the control that converts a static plan into a recurring, observable activity an auditor can sample. SOC 2 Trust Services Criteria and BCP Testing Requirements Availability is one of the five Trust Services Criteria, and it is optional, included only when your service commitments warrant it. When in scope, it is built around three sub-criteria: A1.1 addresses capacity management. A1.2 addresses recovery infrastructure and backup processes. A1.3 addresses the testing of recovery procedures. BCP testing lives squarely in A1.3, with A1.2 supplying the backups and infrastructure that the test validates. Availability Criteria A1.2 and A1.3 Explained Per the AICPA’s Trust Services Criteria, A1.2 requires the entity to design, implement, operate, and monitor environmental protections, recovery infrastructure, and data backup processes that meet its availability objectives. In plain terms: you need real backups, stored away from production, with recovery infrastructure ready to use. A1.3 then requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. The two work as a pair: A1.2 builds the capability, A1.3 proves it functions. Important: The most common A1.3 gap is not a missing test. It is a test that never validated the recovery objectives. Teams run a tabletop, write “no issues found,” and move on — but the plan claims a 4-hour RTO that no one ever measured against an actual restore. If your plan states recovery targets, your test evidence must show whether you met them. A test that does not measure against your RTO and RPO leaves the most important question unanswered. What Auditors Look for During a BCP Test Review Auditors want proof that the test happened, proof that it was meaningful, and proof that it led somewhere. Concretely, that means a test plan with a defined scenario, a dated record of execution with participants, results measured against your recovery objectives, a list of gaps or issues found, and evidence that those issues were remediated. A test that finds nothing and changes nothing is treated with suspicion — because real tests almost always surface something. Types of Business Continuity Plan Tests Accepted for SOC 2 SOC 2 does not mandate a specific test type. It expects the rigor of the test to match the criticality of what you are protecting. The four common approaches sit on a spectrum from low-effort, low-disruption to high-effort, high-assurance. Tabletop Exercises A tabletop exercise is a facilitated discussion where key personnel talk through a disruption scenario and their responses. It is cheap, fast, and excellent for confirming that people understand their roles and that the plan reads coherently. Its limit is obvious: nobody actually recovers anything. For many organizations a tabletop is a legitimate annual test, especially in the first audit cycle, but auditors expect more rigor as a program matures. Walkthrough and Simulation Tests A simulation applies a specific scenario and asks the team to perform recovery actions, not just describe them. It is more involved than a tabletop and far better at exposing the gaps that only appear when people touch the tools. Simulations are where teams discover that a runbook references a system that was decommissioned, or that the on-call engineer lacks the access the plan assumes. Full Interruption Tests A full interruption test shuts down primary systems and shifts operations entirely to the recovery environment. It is the most comprehensive validation available and the only one that proves your failover genuinely works end to end. It also carries real operational risk, so it demands thorough planning and is usually reserved for mature programs and the most critical systems. Parallel Testing Parallel testing activates recovery systems alongside production without taking the primary offline, then compares the two to confirm the recovery environment performs as expected. It delivers much of the assurance of a full interruption test while sparing the business the disruption. For most SaaS and cloud-hosted services, parallel testing of failover and restore is the sweet spot between confidence and risk. How to Test Your Business Continuity Plan for SOC 2 Compliance The sequence below aligns with the contingency planning process in NIST’s Contingency Planning Guide, SP 800-34, which auditors widely treat as authoritative for resilience practices. Each step produces an artifact, and the artifacts together form
A SOC 2 auditor will not ask whether you have an incident reporting policy. They will ask you to pull a specific incident from the last twelve months and walk them through it: when it was detected, who classified it, when it was escalated, who was notified, and how it was closed. The policy is the easy part. The part that fails audits is the gap between what the document says and what the timestamps actually show. Incident reporting sits at the center of the SOC 2 System Operations criteria, and it is one of the most frequently exception-flagged areas in Type 2 reports. The reason is consistent: teams treat reporting as paperwork generated after the fire is out, rather than as a controlled process that produces evidence at every step. This guide breaks down how to build a reporting process that an auditor can test, sample, and sign off on without a finding. What Is the Incident Reporting Process in SOC 2? The incident reporting process is the documented, repeatable sequence your organization follows from the moment a security event is detected to the moment the incident is formally closed and archived. It governs how events are logged, classified, escalated, communicated, and recorded. Reporting is not a single notification email. It is the connective tissue that links detection, response, and post-incident review into an auditable chain. How SOC 2 Defines a Security Incident SOC 2 does not hand you a rigid statutory definition. It works through the AICPA’s Trust Services Criteria, which frame an incident around a failure, or potential failure, of the system to meet the organization’s service commitments and security objectives. In practice, a security incident is any event that compromises, or could compromise, the confidentiality, integrity, or availability of systems or data. The criteria expect you to define this threshold yourself and apply it consistently, which is precisely what auditors test against. What Qualifies as a Reportable Security Incident Under SOC 2? An event becomes reportable when it crosses the threshold your own policy sets. The distinction matters. A blocked phishing email is a security event. A user who clicked the link and entered credentials is a reportable incident. SOC 2 rewards organizations that draw this line explicitly, because a clear definition is what makes consistent triage possible. Vague language like “significant events will be reported” invites the auditor to ask who decides what counts as significant, and on what basis. Examples of Security Incidents Relevant to SOC 2 Common reportable incidents include unauthorized access to production systems, credential compromise, malware or ransomware infection, data exfiltration or accidental disclosure, denial-of-service events affecting availability, lost or stolen devices holding company data, and misconfigurations that expose data to the public. Vendor and subprocessor breaches that touch your data belong on this list, too, since the criteria extend your responsibility into the supply chain. How Incident Severity Levels Are Established and Classified Severity classification drives everything downstream: how fast you respond, who gets pulled in, and which notification clocks start ticking. Most mature programs use a tiered scheme tied to business impact rather than technical noise. The point is not the labels you choose but the fact that the labels map to defined response times and escalation paths, and that the mapping is documented before an incident occurs, not invented during one. Auditors quietly judge your maturity by how few P1s you declare and how consistently you apply the tiers. A program that labels everything critical looks panicked; one that never escalates looks asleep. The strongest signal is a severity matrix with response-time SLAs next to each tier, and ticket history showing the tiers were actually applied as written. SOC 2 Incident Reporting Requirements There is no single “incident reporting requirement” in SOC 2. The obligation is distributed across several Common Criteria, and the auditor assembles a picture from all of them. Understanding which criteria govern reporting tells you exactly what evidence to keep. Which SOC 2 Trust Services Criteria Govern Incident Reporting? Incident reporting lives mainly in the CC7 (System Operations) series. CC7.2 covers monitoring system components to detect anomalies that may signal an incident. CC7.3 requires you to evaluate detected events to determine whether they are incidents and to take action. CC7.4 governs the response itself, including containment, eradication, and communication. CC7.5 addresses recovery and remediation. Communication obligations also reach into CC2.2 and CC2.3, which deal with internal and external information flow, and third-party incidents implicate CC9.2 on vendor risk. These are points of focus, not a checklist, but auditors use them to frame their testing. For a deeper look at how these criteria map to your broader compliance program, see our SOC 2 compliance guide. What Evidence Do Auditors Expect From Your Incident Reporting Process? Auditors want artifacts with time references, not assertions. That means incident tickets showing detection and closure timestamps, severity classifications with the name of who assigned them, escalation records, communication logs, and post-incident review notes. In a Type 2 examination they will trace one real incident end to end. Evidence pulled from a staging environment, or any artifact with no clear date, gets challenged immediately. Who Is Responsible for Reporting Security Incidents? Everyone reports; a defined role decides. SOC 2 expects that all staff know how to raise a suspected incident, and that a named function, often a security lead or incident commander, owns the determination of severity and the decision to escalate. The auditor will look for evidence that this ownership is real: a RACI chart is fine, but ticket history showing the right person actually classified and closed incidents is better. Step-by-Step SOC 2 Incident Reporting Process The following sequence maps cleanly to the lifecycle in NIST’s Computer Security Incident Handling Guide (SP 800-61), which auditors widely recognize as authoritative. NIST withdrew Revision 2 in April 2025 and released Revision 3, which reorganizes the lifecycle around the six functions of the Cybersecurity Framework 2.0. The underlying steps below remain the same; the framing simply shifts toward continuous risk management.