/

  / Drata HIPAA Compliance: PHI Safeguards in 2026

Drata HIPAA Compliance: PHI Safeguards in 2026

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.

Drata HIPAA Compliance - How the Platform Operationalizes PHI Safeguards in 2026

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.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

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 gets notified. This is the difference between point-in-time compliance and continuous compliance: you find out about drift within hours, not at next year’s audit.

Continuous Control Testing and Gap Detection

Drata uses AI to surface why a control is failing rather than simply flagging that it has failed. For HIPAA, this matters because the Security Rule includes both “required” and “addressable” implementation specifications, and “addressable” does not mean optional. Gap detection that explains the underlying issue helps teams document why a particular safeguard was implemented, modified, or substituted with an equivalent measure, which is exactly what 45 CFR §164.306(d) requires. For organizations newer to this process, a structured gap analysis is often the best place to start.

Healthcare-Specific Integrations

Drata integrates with more than 300 systems. For healthcare and HIPAA workflows, the most relevant categories are cloud providers (where ePHI is stored), identity and access management tools (which enforce technical safeguards), endpoint and MDM platforms (which prove device-level encryption), HRIS systems (which drive workforce training and offboarding evidence), and ticketing tools (which provide audit trails for access changes).

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

HIPAA Compliance Checklist in Drata

A HIPAA program in Drata generally breaks into four blocks of work, aligned with how the Security Rule is structured.

Administrative Safeguards

Administrative safeguards cover policies, procedures, and the conduct of the workforce. Drata supports the risk analysis requirement, the single most-enforced provision in 2025, along with security management process documentation, workforce security policies, information access management, training records, contingency planning, and periodic evaluation. The risk analysis module is where most teams will spend the bulk of their setup time, and rightly so given OCR’s current enforcement posture.

Physical Safeguards

Physical safeguards address facility access controls, workstation use and security, and device and media controls. For SaaS-native business associates, much of this is inherited from cloud providers, AWS SOC 2 reports, for example, and Drata’s vendor management module captures that inheritance. For organizations with their own facilities, controls and evidence need to be tracked manually, with Drata acting as the system of record.

Technical Safeguards

Access control, audit controls, integrity controls, person or entity authentication, and transmission security. This is where Drata’s integrations do the most work. Encryption at rest and in transit, MFA enforcement, role-based access, audit logging, and session timeouts can all be evidenced automatically through connected cloud and identity systems.

Organizational Requirements and Policies

This is the Business Associate Agreement (BAA) layer. Drata provides a BAA template and tracks BAA status across vendors that touch PHI on your behalf. The platform also supports the documentation requirements at 45 CFR §164.316, which mandates that all policies, procedures, and required actions are maintained in writing for six years from creation or last effective date.

Pro Tip: When you set up your HIPAA framework in Drata, configure it alongside SOC 2 from day one if both are on your roadmap. Drata reports up to 81% control overlap between the two, and shared control mapping means a single piece of evidence satisfies multiple framework requirements simultaneously. Setting them up separately later means duplicating work you have already done.

HIPAA Risk Assessments with Drata

Risk analysis is the most consequential HIPAA requirement to get right. Of the ten resolution agreements OCR announced in the first five months of 2025, every single one included a finding that the organization had not conducted a compliant risk analysis. Penalties for this single failure ranged from $25,000 to $3 million.

How Drata Supports Risk Assessment and Mitigation

Drata’s risk management module guides teams through identifying assets that store or process ePHI, scoring threats and vulnerabilities, and documenting mitigation owners and timelines. Crucially, it links each identified risk to the specific controls and evidence intended to mitigate it. When a control fails, the linked risk’s posture updates automatically. This is precisely what OCR’s expanded 2026 enforcement focus on risk management, not just risk analysis, is asking organizations to demonstrate.

Mapping Risks to HIPAA Controls in Drata

Each risk in Drata can be mapped to one or more HIPAA controls, and each control is mapped back to specific implementation specifications in 45 CFR Part 164. The result is a defensible chain: identified risk → assigned control → automated evidence → audit-ready documentation. This chain is what counsel will reach for first if OCR opens an investigation following a breach.

HIPAA Training Management in Drata

HIPAA requires workforce training, and OCR has cited training gaps as a contributing factor in multiple recent settlements. Drata addresses this through embedded training content and tracked completion, not just a checkbox.

Annual HIPAA Training Tracking

Drata’s embedded HIPAA training tracks completion at the individual workforce member level, surfaces overdue users, and timestamps every completion event for audit purposes. When OCR asks for training records, this is the artifact that answers the question.

Embedded and Custom Training Workflows

Beyond the built-in modules, organizations can upload their own training content, covering role-specific PHI handling, for example, and assign it through Drata. This is particularly useful for organizations that already have an LMS but want compliance tracking centralized in one place rather than scattered across systems.

Audit Trails for Workforce Compliance

Drata generates a workforce training register with dates, content versions, and acknowledgements. This is one of the artifacts OCR investigators routinely request, and having it on demand significantly reduces the scramble that typically precedes external reviews.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Getting Audit-Ready for HIPAA with Drata

There is no formal HIPAA audit in the way SOC 2 or ISO 27001 have audits. What exists is OCR investigation (triggered by complaints or breaches), HIPAA readiness assessments performed by external firms, and the practical reality that customers and partners increasingly demand attestations of HIPAA compliance as a condition of doing business.

How to Configure Drata for HIPAA Readiness

Initial configuration involves selecting HIPAA as a framework, connecting integrations covering all systems that store or process ePHI, customizing the HIPAA-specific policy templates (including the BAA template), assigning control owners, and running the risk analysis module against a complete asset inventory. Most organizations complete initial configuration in 4 to 12 weeks depending on environment complexity.

Evidence Collection and Audit Documentation

Once configured, Drata acts as the single repository for HIPAA evidence: control statuses, policy versions, training completions, risk registers, vendor BAAs, and access reviews. The platform produces auditor-ready exports that can be shared directly with external assessors or counsel, eliminating the document-request back-and-forth that typically adds weeks to an assessment timeline.

Working with a HIPAA Auditor or CPA Firm

Drata supports auditor workspaces where assessors get scoped access to relevant evidence without seeing the broader environment. For organizations pursuing third-party HIPAA attestations or HITRUST CSF certification, which incorporates HIPAA requirements, this collaboration model substantially reduces the friction of traditional document requests.

Insider Note: OCR investigations average 57 months from complaint or breach notice to enforcement action, according to a 2025 review of recent settlements by law firm Shook, Hardy & Bacon. That is nearly five years. The implication: evidence retention matters enormously. Continuous evidence collection through a platform like Drata is materially easier to defend than reconstructed evidence pulled together after an investigation lands.

Drata HIPAA vs. Other Compliance Frameworks

Most organizations that need HIPAA also need SOC 2, and increasingly ISO 27001 or HITRUST as well. Drata’s design assumption is that controls and evidence should be reused across frameworks rather than duplicated, and the efficiency gains compound quickly once you have more than one framework active.

HIPAA and SOC 2: Different End States, Substantial Overlap

HIPAA is a legal obligation enforced by a federal regulator. SOC 2 is a voluntary attestation that demonstrates security posture to customers and prospects. They are not the same thing, but they share significant ground, particularly around access control, encryption, audit logging, and incident response. For a detailed breakdown of how these two frameworks compare structurally, our ISO 27001 vs SOC 2 guide covers the key architectural differences that also inform how HIPAA fits into the picture.

Running Multiple Frameworks Simultaneously

When multiple frameworks are active in Drata, a single control like “MFA is enforced on all administrative accounts” satisfies SOC 2 CC6.1, ISO 27001 A.9.4.2, and HIPAA §164.312(d) at once. One piece of evidence, three framework requirements. This is the single most important reason organizations consolidate on a GRC platform: the multiplier effect on previously duplicated work compounds quickly as your compliance obligations grow. If you are evaluating which automation platform fits your stack, our Drata vs Vanta comparison walks through how the two leading tools differ in practice.

Does Drata support HIPAA compliance?

Yes. HIPAA was added as Drata’s third framework in late 2021 and is one of more than 30 frameworks the platform supports. Coverage includes the Privacy Rule, Security Rule, and Breach Notification Rule, with mapped controls, policy templates, embedded training, and a BAA template.

Drata maintains its own security and compliance posture, including SOC 2 attestation and signed BAAs with customers who need them. Because Drata may process customer-uploaded evidence that contains references to PHI, signing a BAA with Drata is standard practice for healthcare customers and should be treated as a day-one task.

Drata automates evidence collection for most technical safeguards, access control, encryption, audit logging, transmission security, and parts of administrative safeguards, including workforce training records, access reviews, and contingency plan documentation. Physical safeguards in cloud-native environments are often inherited from cloud provider attestations and managed through vendor management workflows.

No, and it is not designed to. HIPAA requires a designated security officer and privacy officer under 45 CFR §164.308 and §164.530. Drata is the operational tooling that those officers use to do their job effectively. The platform reduces administrative load substantially, but accountability for HIPAA compliance still sits with named individuals inside the organization.

Initial readiness typically takes 4 to 12 weeks for a SaaS company or business associate with a modern cloud stack. Larger or more complex environments may take 3 to 6 months. The variable is not Drata; it is how much foundational work, policies, risk analysis, training, BAA inventory, the organization needs to do for the first time. Organizations already compliant with SOC 2 or ISO 27001 in Drata can typically achieve HIPAA readiness substantially faster because of the control overlap.

Yes. Drata signs BAAs with customers when its handling of customer data could touch PHI. Healthcare organizations and business associates should request and execute a BAA with Drata as part of onboarding. The presence of a signed BAA is itself an audit artifact and should be stored in Drata’s vendor management module alongside all other third-party BAAs.

Evidence is collected automatically through integrations, timestamped, and stored centrally. Drata retains evidence consistent with HIPAA’s six-year documentation requirement under 45 CFR §164.316(b)(2). Auditors and assessors can be granted scoped workspace access without exposing the broader environment, and exports are available for any required external review.

OCR’s enforcement priorities have not been subtle: do the risk analysis, manage the risks you find, and document everything in a way that survives a multi-year investigation timeline. Drata is built for that pattern of work. If you want to understand how it fits your specific environment, whether you are a covered entity, a business associate, or a healthcare technology company scaling into enterprise contracts, talk to an expert who can map the right framework strategy to where you actually are.

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

Compliance software collects the evidence. A consultant builds the system that evidence is meant to prove. That’s the real difference in the ISO 27001 consultant vs software decision, and most teams only figure it out after they’ve bought one and realized they still need the other. Below, we compare what each route covers, where it breaks down, and what it costs you in time, money, and your team’s hours. Short version: software on its own works for a small group of companies. For most SaaS and tech scale-ups trying to get an enterprise deal over the line, consultant-led implementation on a compliance platform is the faster and safer path to a certificate. Quick Answer: Consultant, Software, or Both? Software-only works if you already have an in-house security lead who’s taken a company through ISO/IEC 27001 before and has the time to own the project. Consultant-only still makes sense if you run mostly on-premise or legacy systems that platforms barely integrate with. For everyone else, which means most cloud-native companies under a few hundred people, a hybrid works best: a platform to handle evidence and monitoring, and a consultant to build the management system and stand behind it in front of an auditor. Here’s why. What an ISO 27001 Consultant Handles ISO/IEC 27001:2022 is a management system standard. Clauses 4 to 10 cover how you run information security, and Annex A lists 93 controls you pick from based on risk. Almost none of it is box-ticking. Most of it comes down to judgment calls about your business, and that’s what you’re paying a consultant for. Scoping, Gap Analysis and Risk Assessment Scope is the first decision you make, and the most expensive one to get wrong. Go too wide and you’ll spend months on controls for systems no customer asks about. Go too narrow and the certificate won’t get through the procurement review it was supposed to pass. A consultant scopes around the deals you’re trying to close, runs a gap analysis, and builds a risk assessment based on your real assets and threats. That’s the document auditors dig into hardest. ISMS Documentation and Policy Writing The standard asks for a specific set of documents: the ISMS scope, information security policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, and evidence of competence, monitoring, internal audit, and management review. A consultant writes these around how your company works day to day, instead of how a template imagines it works. Auditors check whether you follow your own procedures, so a mismatch shows up fast. Internal Audit and Certification Audit Support You need an internal audit before certification, and Clause 9.2 says the auditor has to be objective and impartial. In a small company, the people who built the ISMS can’t credibly audit it, so most teams outsource it through ISO 27001 internal audit services. A good consultant also gets your team ready for the Stage 1 and Stage 2 audits, joins the conversations that matter, and handles corrective actions if the auditor raises nonconformities.  What ISO 27001 Compliance Software Handles Compliance automation platforms, often called GRC platforms, have changed how cloud-native companies get certified. They’re very good at the repetitive, evidence-heavy side of the work. Automated Evidence Collection and Continuous Control Monitoring The platform plugs into your cloud provider, identity provider, code repos, HR system, and device management tools, then pulls evidence on its own. It’ll flag an unencrypted storage bucket, an ex-employee who still has access, or a laptop without disk encryption. For technical controls, that saves weeks of screenshots and spreadsheet tracking. Policy Templates and Annex A Control Mapping Most platforms come with a policy library and map each control to the ISO 27001 clauses and Annex A. You get a starting point and a clear view of which controls have evidence and which don’t. Auditor Access and Ongoing Compliance Tracking Auditors can log in and review evidence themselves, which cuts down fieldwork. After you’re certified, dashboards show when controls slip between surveillance audits, so you aren’t rebuilding evidence from scratch every year. Where Each Approach Falls Short Neither route covers everything by itself. The good news is that the ways each one fails are predictable, so you can plan around them. Limits of Compliance Automation Platforms A platform can tell you a control is failing. It can’t decide your scope, run your risk assessment, write a policy that matches your operations, convince your CTO to change the offboarding process, or explain to an auditor why you excluded a control from your Statement of Applicability. Templates can also make you feel further along than you are. A dashboard at 90% can hide an ISMS that won’t survive Stage 1, because the missing 10% is the management system itself. Insider Note: The Stage 1 problem we see most on software-only projects is a risk assessment copied straight from the platform’s default risk library. The risks are generic, the scores are almost identical, and nothing ties back to the company’s own assets. Auditors notice within minutes, and it weakens the Statement of Applicability that’s built on it. The other problem is ownership. Software assumes someone inside the company will drive the project. At most startups that’s a CTO or ops lead who already has a full-time job, and the subscription renews whether the work gets done or not. Limits of a Consultant-Only Approach A consultant working without automation spends billable days on things a platform does for free, like chasing screenshots, updating evidence trackers, and collecting the same proof again before every surveillance audit. You pay more and wait longer. You also end up with a program that’s only accurate on the day it’s handed over. Once the engagement ends, the evidence goes stale and year-two surveillance turns into a scramble. ISO 27001 Consultant vs Software: Side-by-Side Comparison Factor Consultant only Software only Hybrid (consultant + platform) Time to audit readiness 3 to 6+ months Highly variable; depends on internal expertise As little as 6 weeks for well-scoped

Uzbekistan regulates artificial intelligence through two documents. The first is Law ZRU-1115, signed on 21 January 2026. It amends existing legislation to define AI, stops anyone from basing decisions about people’s rights on AI output alone, and fines companies that process personal data unlawfully with AI. The second is the set of Ethical Rules approved by Order No. 3787, in force since 17 June 2026, which spell out what developers, implementers, and users actually have to do. Uzbekistan hasn’t passed a standalone AI act, and its rules don’t sort systems into risk tiers or require conformity assessments. The framework is short and blunt, and it’s already enforceable. Below we walk through what each document requires, who it applies to, how it stacks up against the EU AI Act, and what a company using AI in Uzbekistan should do next. Uzbekistan AI Regulation at a Glance (TL;DR) Instrument Date What it does Who it binds Law ZRU-1115 Signed 21 January 2026 Defines AI in law, sets general rules for AI-built information resources and systems, bans legally significant decisions based only on AI, adds fines for unlawful AI processing of personal data State bodies, organizations, website owners, anyone processing personal data with AI Order No. 3787 (Ethical Rules) Registered 14 March 2026, in force 17 June 2026 Sets eight mandatory ethical principles and lists rights and obligations for developers, implementers, and users Individuals and companies developing, implementing, or using AI in Uzbekistan Law No. 1125 (Personal Data amendments) Adopted 26 March 2026 Limits data localization to biometric, genetic, and local telecom user data, and allows cross-border transfers under conditions Personal data operators, including AI providers AI Strategy until 2030 (RP-358) 14 October 2024 Sets national targets for AI adoption, infrastructure, and skills Government bodies What Is Law ZRU-1115? The law’s official title is a mouthful: “On making additions and changes to certain legislative acts of the Republic of Uzbekistan in connection with the regulation of relations arising from the use of artificial intelligence.” Put simply, it’s an amending law. Instead of creating a new AI code, it writes AI into laws that were already on the books. When It Was Signed and When It Took Effect The Legislative Chamber of the Oliy Majlis adopted the bill on 12 August 2025, and the Senate approved it on 1 November 2025. President Shavkat Mirziyoyev signed it on 21 January 2026. You can read the official text in Lex.uz, Uzbekistan’s national legislation database. The law set out the principles and the penalties. The day-to-day detail arrived later with the Ethical Rules, which came into force on 17 June 2026. For compliance planning, treat mid-June 2026 as the point when the whole framework started applying. Why Uzbekistan Amended Existing Laws Instead of Passing a Standalone AI Act Uzbekistan wants more AI, not less. Its national strategy sets numeric targets for adoption, investment, and local computing capacity, and a heavy EU-style act would have worked against them. So lawmakers kept it light. They defined AI, drew two hard lines (human control over decisions that affect people’s rights, and protection of personal data), and left the Ministry of Digital Technologies to fill in the rest through secondary rules. Businesses get less legal certainty, and the government gets to move faster. Which Laws ZRU-1115 Changes For businesses, two amendments matter most. The Law “On Informatization” (ZRU-560-II, 2003) now contains a legal definition of AI, a new article on using AI in information resources and systems, duties for website owners, and updated powers for the ministry in charge. The Code on Administrative Liability now includes an offense for processing and spreading personal data unlawfully using AI. The Legal Definition of Artificial Intelligence in Uzbekistan Under the amended Law “On Informatization,” AI is a set of technological solutions that imitate human cognitive functions, including learning on their own and solving problems, and that produce results on specific tasks comparable to what a person could do. That’s deliberately broad. It covers generative AI, machine learning classifiers, recommendation engines, and most agentic systems. The Ethical Rules add a narrower term, the AI system: software built on AI that can find, collect, store, analyze, process, evaluate, and use data, and make decisions on its own based on that data. If your product makes a decision from data, or shapes one, assume it counts. Key Rules Introduced by Law ZRU-1115 General Principles for Using AI in Information Systems and Resources The new article in the Law “On Informatization” starts from harm. Information resources created with AI, and information systems running on AI, must not harm people’s life, health, freedom, honor, or dignity, or violate their other inalienable rights. The standard is short and open-ended. It gives regulators something to enforce against without saying in advance what counts as harm. Principle-based rules like this deserve to be taken seriously precisely because the edges are undefined. Human Oversight: No Decisions on Rights and Freedoms Based Solely on AI Most coverage leads with this provision, and it’s easy to see why. When someone makes a legally significant decision that affects human rights and freedoms, they can’t rely only on conclusions produced by AI systems or AI-built information resources. AI can feed into the decision, but a person has to make it. That applies to loan denials, benefit eligibility, hiring rejections, licensing outcomes, and disciplinary action. In each case, someone needs to look at the AI output and own the final call. Insider Note: In AI governance engagements, teams rarely struggle to show that a review step exists. What they struggle to show is that the reviewer could disagree, and sometimes did. If a human clicks “approve” on every AI recommendation and nobody ever records an override, auditors will see automation with a signature on top. Build the override path and log when people use it, starting on day one. Powers of the Authorized State Body (Ministry of Digital Technologies) ZRU-1115 makes the Ministry of Digital Technologies the authorized state body for AI. Among its new jobs, it’s

You can get a SaaS company ready for a SOC 2 audit in six weeks, but you’ll feel every one of them. Most published timelines say three to six months. For a company with no project owner, no identity provider, and nothing written down, that’s about right. A cloud-native startup that already has the basics in place and can protect some time is a different story, and it can fit the work into six hard weeks. This plan walks through that route one week at a time. Each week has an owner, an hour estimate, and a clear test for when it’s finished. The free Google Sheet version turns the plan into a tracker you can hand out to owners and update in your weekly standup. Before you start, know what you’re signing up for. At the end of week 6 you’ll be audit-ready, which isn’t the same as holding a Type II report. Nobody can get you a Type II in six weeks. This is also the do-it-yourself route, and it takes a lot of hours. We’ll show you where those hours go and what the faster option looks like. Is Six Weeks Realistic for Your Company? Six weeks works when most of the plumbing already exists and your job is to formalize it, fill the gaps, and prove it all works. It falls apart when you’re building the foundations and documenting them at the same time. Go through this table honestly before you promise a customer a date. Six weeks is realistic if… Plan for 10 to 16 weeks if… Your product runs on a major cloud provider You host on-premise or across several data centers You already use an identity provider with SSO Every tool has its own login and password You have fewer than about 50 employees You have multiple offices, subsidiaries, or products in scope One named person owns the project with 10 to 15 hours a week Compliance is “everyone’s job,” so in practice nobody owns it An engineer can give you 15 to 20 hours in weeks 3 and 4 Engineering is fully committed to a launch You only need the Security criteria You need Availability, Confidentiality, or Privacy on day one Landing mostly in the right-hand column doesn’t mean you should throw the plan out. Give each week two weeks instead of one and follow the same order. What “SOC 2 Ready” Means at the End of Week 6 SOC 2 doesn’t give you a certificate. An independent CPA firm examines your controls against the AICPA Trust Services Criteria and writes a report, and which of the two report types you go for decides what you can show a buyer after week 6. A Type I report checks whether your controls are designed properly on a single date. Once you’re ready, a Type I audit can start almost right away. A Type II report checks whether those controls kept working over an observation period of at least three months, and usually six to twelve. Most enterprise procurement teams want Type II in the end. Being “ready” at the end of this plan means your in-scope controls are in place, you can pull evidence for any of them on request, and your auditor is booked. From there you either start a Type I audit or open your Type II observation window. Plenty of buyers will sign with a Type I report plus a letter from your auditor saying the Type II period is underway. Important: The Type II clock doesn’t start until your controls are running. If readiness slips by a week, your Type II report slips by a week too. Founders who tell a prospect “we’ll have SOC 2 in Q3” often forget this and end up renegotiating the deal. Before Week 1: Four Decisions to Make First Settle these before the clock starts. If you change any of them halfway through, you’ll redo work. Scope. Decide which systems, teams, and data the report covers. For most SaaS companies that’s the production environment, the code repository, the identity provider, customer data stores, and any support tools that touch customer data. Corporate systems that never see customer data can usually stay out. Trust Services Criteria. Security (also called the Common Criteria) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Report type. Pick Type I if a deal is blocked right now and the buyer will accept it. If there’s no deadline, go straight to Type II. You’ll need it eventually, and skipping Type I saves you an audit fee. Owner and tooling. Name one person who’s accountable for the plan, and decide where your controls and evidence will live. The tooling choice gets its own section below. Pro Tip: Adding Criteria Only add optional criteria when a customer contract or security questionnaire asks for them. Each one brings more controls to set up and more evidence to collect, and you can widen the scope in next year’s audit. Spreadsheet or Compliance Software: Choosing Your Tracking Tool Every SOC 2 program needs a system of record, meaning one place where each control, its owner, its status, and its evidence live. You can run it yourself in a spreadsheet or a GRC platform, or have a consultant implement it for you. The right choice depends mostly on which report you’re after and how much of your team’s time you can spare. A spreadsheet is free and familiar. It also makes you understand your own environment before you automate any of it. For a Type I, or for a small team with a tight scope, a well-built spreadsheet can take you all the way to the audit. Axipro’s free GRC workbook for SOC 2 and ISO 27001 covers all 33 SOC 2 Common Criteria plus the optional criteria, with evidence, risk, policy, and gap trackers built in. It has no macros and opens straight in Google Sheets or Excel. A GRC platform connects to your cloud, identity provider, code repository, and HR system.