Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / ISAE 3000 vs SOC 2: Key Differences, Equivalencies, and Which Report You Need

ISAE 3000 vs SOC 2: Key Differences, Equivalencies, and Which Report You Need

A practical guide for SaaS companies, cloud vendors, and security teams navigating international assurance reporting.

If you have ever been deep in a vendor due diligence questionnaire and hit the question “Do you have a SOC 2 or equivalent report?” you are not alone. For companies operating across borders, the follow-up question is almost always: is ISAE 3000 the same as SOC 2?

The short answer is no. The two standards share real overlap and can sometimes be combined into a single engagement, yet they serve fundamentally different markets. Getting this wrong can mean buying the wrong report, overpaying for duplicate audits, or confusing procurement teams who needed one thing and received another.

This guide breaks down what each standard covers, where they diverge, and how to decide which report is right for your organisation.

ISAE 3000 vs SOC 2

 What “ISAE 3000” and “SOC 2” Actually Mean

ISAE 3000: The International Assurance Standard for Non-Financial Reporting

ISAE 3000 is an international standard issued by the International Auditing and Assurance Standards Board (IAASB), operating under the International Federation of Accountants (IFAC). It governs assurance engagements on any subject matter that is not a historical financial statement audit or review: sustainability reports, ESG disclosures, cybersecurity controls, privacy programmes, or, most relevant here, information security controls. Effective for reports dated on or after 15 December 2015, it applies worldwide. Its flexibility is both its strength and its source of confusion: ISAE 3000 does not prescribe which criteria to evaluate. It provides the rules for how a practitioner should conduct a non-financial assurance engagement, including planning, evidence gathering, risk assessment, and reporting.

SOC 2: The AICPA Report Based on the Trust Services Criteria

SOC 2 is a reporting framework developed by the American Institute of Certified Public Accountants (AICPA). It examines the design and operating effectiveness of a service organisation’s controls against the AICPA’s five Trust Services Criteria (TSC): Security (the mandatory baseline, also called the Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 examinations are performed under SSAE 18 (specifically AT-C Section 205), the US attestation standard. Reports are restricted-use by default, shared with management, user entities, business partners, and regulators who have sufficient understanding of the system under examination. Since 2017, SOC 2 Type II has become the de facto compliance benchmark for SaaS and cloud companies serving US enterprise customers.

Are ISAE 3000 and SOC 2 Direct Equivalents?

No. ISAE 3000 is an assurance methodology, a set of rules for how to conduct the engagement. SOC 2 is a report type with pre-defined criteria (the TSC). One tells the auditor how to work; the other tells them what to assess. They operate at different layers of the compliance stack, which is why they can sometimes be combined. The confusion is understandable. Both involve independent third-party assurance on information security controls. Both result in a written opinion. And in practice, a European auditor may conduct an engagement under ISAE 3000 while using the AICPA Trust Services Criteria as the evaluation benchmark, producing something that looks like a SOC 2 report but technically is not one.

Core Differences: ISAE 3000 vs SOC 2

ISAE 3000 vs SOC 2: Head-to-Head Comparison

Dimension ISAE 3000 SOC 2
Standard Setter IAASB / IFAC AICPA
Governing Standard ISAE 3000 SSAE 18 (AT-C 205)
Subject Matter Any non-financial subject matter Trust Services Criteria only
Criteria Used Flexible (must be “suitable”) AICPA TSC (fixed)
Assurance Levels Reasonable or Limited Reasonable only (Type II)
Report Distribution General-purpose or restricted Restricted-use
Geographic Strength International (EU, UK, APAC, MEA) US / Canada
Type I / Type II Point-in-time or period testing Type I (point) or Type II (period)
Audit Firm Requirement Licensed practitioner (CPA or equivalent) Licensed CPA firm (US AICPA)
Can Use TSC as Criteria? Yes, if deemed suitable Yes (mandatory)

Standard Setter and Framework Owner

ISAE 3000 is maintained by the IAASB, a global body whose standards are adopted in over 130 jurisdictions. SOC 2 is governed by the AICPA, the professional body for US CPAs. A CPA firm in London cannot natively issue a “SOC 2” report (that branding belongs to the AICPA ecosystem), but a UK firm can issue an ISAE 3000 assurance report that evaluates controls against the Trust Services Criteria.

Subject Matter Flexibility

ISAE 3000 is deliberately subject-matter agnostic. It can be applied to carbon emissions data, anti-bribery controls, ESG metrics, data privacy programmes, or security controls. SOC 2, by contrast, is locked to the Trust Services Criteria. Security is always in scope; the four remaining categories are optional add-ons chosen based on the service organisation’s commitments.

Criteria: Suitable Criteria Under ISAE 3000 vs AICPA Trust Services Criteria

Under ISAE 3000, the practitioner must confirm that the chosen criteria are suitable, meaning they are relevant, complete, reliable, neutral, and understandable. The AICPA’s TSC can serve as suitable criteria under ISAE 3000, but so can ISO 27001 control objectives, NIST CSF categories, or a bespoke set of criteria. In a SOC 2 engagement, the criteria are not negotiable. You use the TSC. Period.

Report Distribution: General-Purpose vs Restricted-Use

SOC 2 reports carry a restricted-use designation, intended for parties with sufficient knowledge of the system (though in practice, many organisations share them under NDA). ISAE 3000 reports can be either restricted-use or general-purpose, depending on the nature of the criteria. If criteria are publicly available and broadly understood (e.g., ISO 27001), the report may be issued for general distribution.

Assurance Level: Limited vs Reasonable

ISAE 3000 explicitly supports both reasonable assurance (high-level confidence, positive-form opinion) and limited assurance (moderate confidence, negative-form opinion: “nothing has come to our attention…”). SOC 2 Type II provides reasonable assurance only. There is no “limited assurance SOC 2.” A company needing a lighter-touch review may find an ISAE 3000 limited assurance engagement faster, cheaper, and sufficient.

Pro Tip: EU and UK Customers

If your EU or UK customers ask for “an ISAE 3000 report” without specifying the assurance level, clarify upfront. A limited assurance engagement involves materially less testing and a lower fee, but some enterprise buyers will only accept reasonable assurance. Getting alignment early saves weeks of rework.

Geographic Recognition and Market Expectation

SOC 2 dominates in the United States and Canada. In the EU, UK, Middle East, Asia-Pacific, and Africa, ISAE 3000 (and its cousin ISAE 3402 for financial reporting controls) is the recognised standard. Multinational companies often need both or a carefully scoped hybrid.

Scope Comparison: What Each Report Typically Covers

Every SOC 2 engagement must include the Security category (Common Criteria), covering logical and physical access controls, system operations, change management, and risk mitigation. The remaining four categories are added based on the services provided and customer expectations. The report includes a System Description prepared by management, detailing the system’s boundaries.

An ISAE 3000 engagement’s scope is whatever the practitioner and engaging party agree upon. When used for security assurance, the scope often mirrors SOC 2. But it could equally focus on GDPR compliance, data processing agreements, or a proprietary control framework. There is no standardised “System Description” format equivalent to what the AICPA prescribes for SOC 2.

On subservice organisations, SOC 2 uses well-defined approaches: the inclusive method (subservice controls are tested) or the carve-out method (subservice controls are excluded). ISAE 3000 does not prescribe specific handling methods, though practitioners typically adopt the same model in practice.

Common Use Cases: When Buyers Search “ISAE 3000 vs SOC 2”

The most common scenario is a SaaS company chasing enterprise customers in multiple geographies. US buyers want a SOC 2 Type II. European buyers may accept or specifically request an ISAE 3000 report because their procurement policies reference IAASB standards. For vendors caught in the middle, understanding whether a single engagement can serve both audiences is critical.

EU and UK procurement teams often operate under frameworks influenced by the European Banking Authority (EBA) outsourcing guidelines or sector-specific regulations that reference ISAE-based assurance. Meanwhile, US enterprise buyers look for the “SOC 2 Type II” label specifically. This tension is something many growing companies discover only after receiving conflicting requests in the same quarter.

Pro Tip: What Procurement Teams Actually Accept

In our experience at Axipro, most sophisticated procurement teams care about three things: (1) that an independent auditor tested your controls, (2) that the criteria used are recognised and rigorous, and (3) that the report covers a recent period (ideally the last 12 months). Whether the cover page says “SOC 2” or “ISAE 3000” matters less than you think, unless the policy explicitly mandates one or the other. Always ask.

SOC 2 Type I vs Type II vs ISAE 3000 Engagement Periods

SOC 2 Type I assesses control design at a specific point in time. SOC 2 Type II tests operating effectiveness over a defined period, typically 6 to 12 months. Type II is what most enterprise buyers want: evidence that controls actually worked over a meaningful timeframe, not just that they existed on paper.

ISAE 3000 supports both point-in-time and period-of-time engagements, mirroring the Type I / Type II distinction. However, the “Type I” and “Type II” labels are AICPA-specific and not used in the ISAE standard itself. In practice, auditors conducting ISAE 3000 security engagements almost always adopt the period-based model.

Pro Tip: What Customers Prefer

Across both SOC 2 and ISAE 3000, vendor risk teams overwhelmingly prefer period-based (Type II equivalent) reports. A point-in-time report can unblock an initial deal, but for annual renewals, period-based testing is the gold standard.

How an “ISAE 3000 SOC 2” Works in Practice

This is the hybrid approach many international companies find most practical. A practitioner (typically a Big Four or mid-tier firm with both AICPA and IAASB credentials) conducts the engagement under ISAE 3000 but evaluates the organisation’s controls against the AICPA Trust Services Criteria. The resulting report references both the assurance standard and the criteria.

This hybrid is not a SOC 2 report in the strict AICPA sense. It will not carry SOC 2 branding. But it provides equivalent substance: the same criteria were tested, by an independent practitioner, under a recognised assurance standard. Many international procurement teams accept this.

If you go this route, ensure the report clearly states: (a) the assurance standard used (ISAE 3000), (b) the evaluation criteria applied (AICPA TSC), (c) management’s assertion or description of the system, and (d) the intended users.

Common Misunderstandings: “Certified SOC 2” and “SOC 2 Accreditation”

Let’s clear this up: there is no such thing as “SOC 2 certification” or “SOC 2 accreditation.” SOC 2 is an attestation engagement resulting in an auditor’s opinion, not a certificate. You do not “pass” or “fail.” The same applies to ISAE 3000. Vendors who claim to be “SOC 2 certified” are misusing the terminology, and savvy buyers will notice.

Which One Should You Choose?

Choose SOC 2 when your customers’ procurement policies specifically name SOC 2. Do not overthink it. A SOC 2 Type II from a reputable CPA firm is the most widely accepted compliance artefact in North America. Our SOC 2 compliance checklist can help you prepare.

Choose ISAE 3000 when your customer base is primarily European, Middle Eastern, or Asia-Pacific and your buyers reference IAASB standards. This is also the right choice when your assurance needs extend beyond security controls into areas like ESG, data privacy, or operational resilience.

Choose a SOC 2-aligned ISAE 3000 when you sell to both US and international enterprises. The hybrid approach can serve as a pragmatic bridge. Some firms also run parallel engagements: a formal SOC 2 for US customers and an ISAE 3000 report for everyone else, reusing the same evidence across both.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Can You Combine ISAE 3000 and SOC 2?

Yes, and it is increasingly common. The key requirement is that your audit firm has practitioners qualified under both AICPA and IAASB standards. The underlying evidence collection (walkthroughs, control testing, documentation review) can be performed once, with the results reported under two frameworks.

The efficiency gain comes from your internal control library. If you have already mapped controls to the TSC for SOC 2, overlaying ISAE 3000 is largely a matter of confirming that the same controls satisfy the suitable criteria requirements. Compliance automation platforms (which Axipro integrates with) can map a single control to multiple frameworks simultaneously.

Pro Tip: Avoiding Scope Creep

When running a combined engagement, agree scope boundaries in writing before fieldwork begins. It’s tempting to expand (“while we’re here, let’s also cover GDPR Article 28…”), but scope creep inflates costs and delays issuance. Keep it focused on what your customers actually need.

Common Pitfalls When Deciding Between ISAE 3000 and SOC 2

Buying the wrong report for your target market. A SOC 2 report won’t satisfy a UK financial regulator expecting ISAE-based assurance. Conversely, handing a US enterprise buyer an ISAE 3000 report when they asked for SOC 2 creates friction, even if the substance is equivalent.

Overpromising scope. Including Privacy, Availability, and every subservice organisation in your first report sounds comprehensive but massively increases the audit burden. Start with Security (Common Criteria), get a clean opinion, and expand in subsequent years. For more on this, see our guide to avoiding common pitfalls in SOC 2 and ISO 27001.

Confusing assurance with certification. Neither SOC 2 nor ISAE 3000 is a “certification.” Do not put “SOC 2 Certified” on your website. The AICPA provides a specific SOC logo programme for organisations that have completed an examination. Use that instead.

Final Thoughts

Ultimately, the ISAE 3000 vs SOC 2 decision comes down to who you’re selling to and where they sit. US enterprise buyers expect SOC 2 by name. International buyers expect ISAE-based assurance. And if you’re serving both, a hybrid or parallel approach can save you from running two entirely separate audits. The important thing is to make this decision early, scope it correctly, and work with an audit partner who understands both frameworks. Get it right, and your compliance report becomes a deal accelerator rather than a bottleneck.

Is ISAE 3000 the international equivalent of SOC 2?

Not exactly. ISAE 3000 is a broader assurance standard. When used to assess security controls against the TSC, it produces a functionally similar report, but it is not the same product.

The SOC 2 label belongs to the AICPA framework. A non-US firm can issue an ISAE 3000 report using the TSC as criteria, which many international buyers accept. Some global audit firms with US-licensed CPAs can issue SOC 2 reports from non-US offices.

ISAE 3000 does not specify criteria. The TSC can be used as evaluation criteria within an ISAE 3000 engagement, provided they are deemed suitable.

Some will, many won’t. US procurement policies frequently name SOC 2 specifically. If your primary market is the US, get a SOC 2.

A first-time SOC 2 Type II typically takes 4–6 months end-to-end (including readiness and remediation), though with the right partner it can be done in weeks, not months. An ISAE 3000 engagement of comparable scope follows a similar timeline. Combined engagements may add 2–4 weeks for dual reporting.

ISAE 3000 supports both point-in-time and period-based testing, which is conceptually the same. However, the “Type I / Type II” terminology is AICPA-specific.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

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