Audit Readiness Starts in Your Live Systems, Not Your Policies

Published On

August 11, 2026

Share this post

Auditors and regulators expect more than paperwork. They check your systems directly to confirm the controls you documented are actually running.

Picture a program that looks complete on paper: policies current and reviewed, access controls following least privilege, data encrypted at rest and in transit, an incident response plan with up-to-date contacts. By your internal standards, it's done.

Then the assessor asks for something specific — a current list of admin accounts, log-retention settings for the systems that hold regulated data, proof of your latest restore test, records showing you fixed the vulnerabilities you found last quarter. And often no one can answer right away, because nobody has checked the system in a while.

That space between what your policies say and what your systems actually do is where audits are lost and breaches begin. Auditors notice it. So do attackers. To be genuinely audit-ready, your production environment and your documentation have to match — because you can pass a policy review and still fail the audit.

What regulators now ask for after an incident

The clearest recent statement of this comes from the regulator most SMB compliance leaders in healthcare answer to. On 8 April 2026 the HHS Office for Civil Rights published guidance on risk management under the HIPAA Security Rule, presented by Nicholas Heesters, its Senior Advisor for Cybersecurity. The message, per legal analyses of the video, was blunt: policies and procedures alone are not sufficient evidence that a security measure was implemented.

OCR wants proof the control is working. Configuration records that match your policies. Event logs and monitoring records showing someone actually watched the system. Change records and remediation tickets showing that when you found a risk, you made a decision and closed it. And OCR is explicit that risk management is ongoing — controls need regular review as threats, technology, and your organization change.

The reason this framing matters: it measures what is happening, not what is written. The HIPAA Security Rule requires an accurate look at the risks to electronic protected health information, and accuracy is a property of your real environment, not your binder. A policy states intent. To know whether a control works, you have to look at the live system.

Why policy and production drift apart

The gap is rarely deliberate. Policies are accurate the day they're approved; it's the incremental decisions afterward that go undocumented. A few familiar examples:

A vendor needs access for a migration, so an account with broad privileges is created — and left active after the project ends.
An integration breaks on MFA, so a conditional-access exclusion goes in as a temporary fix — and quietly persists for more than a year.
A server fails and is rebuilt. It looks healthy, but the log-forwarding agent was never restored, and thin monitoring means nobody notices.
Nightly backups report success, but with no routine restore test nobody catches the repository that has been producing empty archives since a firmware update in March.
An employee departs and the directory account is disabled promptly — but admin access to a SaaS platform licensed separately from the identity provider stays live.
A firewall rule opened for a temporary project is never removed.

Emry calls this compliance drift, and its defining feature is the absence of an alert. A failed backup job pages someone; a documented control that has silently diverged from the real configuration does not — especially when the only thing reviewing it is an annual read of the policy library. Those reviews tend to confirm the assumptions already in the binder.

The evidence gap that shows up in enforcement

Recent enforcement shows the consequences are real. On 23 April 2026 OCR announced settlements with four regulated entities following separate ransomware investigations. Between them the incidents affected more than 427,000 individuals; the organizations paid a total of $1,165,000 and entered two-year corrective action plans under OCR monitoring. The announcement marked 19 completed ransomware investigations and 13 completed under OCR's Risk Analysis Initiative.

Read the four summaries and one thread runs through every one: OCR found each entity had failed to conduct an accurate and thorough risk analysis of the risks and vulnerabilities to its own electronic protected health information. The detail worth sitting with is in the Consociate matter — a successful phishing attack in July 2020 and ransomware that encrypted systems in November and December 2021. The attacker's foothold sat in that environment for roughly seventeen months before the payload landed.

The exposure

These organizations had policies and followed regulations. What they couldn't show was that their understanding of their environment matched reality — and the penalties were for that gap, not for being breached.

The takeaway isn't that documentation is worthless. It's that documentation alone won't prevent an incident or satisfy a regulator. Real control means enforced settings, reviewed logs, alert thresholds, and managed access — each of which can only be confirmed in the live system.

Frameworks already assume production, not paperwork

Some compliance leaders treat validating controls in production as optional, or a matter of taste. The major frameworks already require it — the requirement is just easy to miss.

SOC 2 is an attestation about operation, not a certificate

Under the AICPA attestation framework, a SOC 2 Type 2 report is an independent auditor's opinion on both the design and the operating effectiveness of your controls across a period — usually three to twelve months. There is no SOC 2 certificate. The report documents the test procedures and the results from your systems, and where a control is well designed but not consistently followed, that becomes an exception. The observation period exists precisely because design alone isn't enough.

PCI DSS moved the standard toward continuous operation

PCI DSS v4.0 introduced 64 new or updated requirements, 51 of which became mandatory on 31 March 2025 — and many govern how systems actually run, not what's written. Requirement 11.6.1 calls for change-and-tamper detection on payment pages; Requirement 12.3.1 requires a targeted risk analysis for each requirement, letting you set the frequency of an activity — a frequency an assessor will then check you against and expect you to justify with evidence.

The proposed HIPAA Security Rule update remains pending

Precision matters here, because this is routinely misreported. The Notice of Proposed Rulemaking to overhaul the HIPAA Security Rule was published in the Federal Register on 6 January 2025, and the comment period closed on 7 March 2025. As of July 2026 no final rule has issued, OCR has not confirmed a timeline, and the proposal could still be finalized as written, materially revised, delayed, or withdrawn. It is not law, and nobody should be told otherwise.

What it does show is direction. The proposal would require a written asset inventory, a network map, removal of the “addressable” label from implementation specifications, and controls such as MFA and encryption — all of it pointed at the real environment rather than the policy set. The current Security Rule already expects that discipline; the proposal would sharpen it.

Policy-first vs production-first, side by side

The difference between a program that documents compliance and one that operates it comes down to where the evidence lives.

Two ways to be “compliant”

The axis	Policy-first	Production-first
Definition of done	The policy is approved and the ticket is closed.	The control is running in production and the evidence exists.
What gets measured	Uptime, ticket volume, response time.	Security posture, control coverage, audit readiness.
Evidence	Assembled in the weeks before the audit.	Generated continuously as a byproduct of operating.
Access changes	Granted on request, reviewed when someone remembers.	Granted against a standard, reviewed on a cadence, logged.
Backups	The job reports success.	The restore is tested and the recovery time is known.
Findings	Documented in a report and revisited next year.	Owned, prioritized by risk, closed, and re-verified.
Audit day	A scramble to reconstruct what happened.	An export of what was already being tracked.

That right-hand column is what a defensible IT operating model produces as a matter of course.

What a live system assessment actually examines

An assessment that reviews live systems checks each control three ways: how the system actually behaves, whether that matches the framework requirement, and whether it aligns with what you previously told auditors. In practice it works through the environment along these lines:

Asset inventory first — every later check depends on it. You can't validate controls on systems you don't know exist, and those are often the most exposed. It's why the proposed HIPAA update makes an inventory mandatory.
Identity and access — who actually holds privilege today, orphaned and inactive accounts, what service accounts can reach, MFA exclusions and who approved them, and whether break-glass credential use is alerted.
Endpoint coverage — checked against the asset inventory for gaps. Most coverage gaps come from incomplete inventories, not licensing.
Logging and monitoring — is logging enabled on the systems holding regulated data, retained for the required window, forwarded somewhere, and actually reviewed? Could you produce twelve months of records for a named system on request?
Encryption and backups — data encrypted wherever it rests, including backup repositories, portable media, and file shares that were never meant to be permanent; and restores tested with documented recovery times, because a successful backup job only proves it ran, not that you can recover.
Patch and vulnerability management — time-to-remediate as a measured number, plus an exception register where exceptions have owners and expiry dates.
Third-party connections and data flows — vendor tunnels and integrations, and whether your agreements actually describe the data movement that's happening.
Change and remediation records — findings linked to decisions, actions, and dates. Regulators ask for this constantly; many programs can't produce it.

None of this requires taking systems offline. It requires the right access, a clear process, and defined ownership — the same discipline we cover in our guide to preparing for a compliance audit without disrupting daily operations.

Where your compliance platform fits in

Most compliance leaders run a compliance platform as their system of record: it holds the policy library, maps controls to frameworks, schedules evidence collection, tracks reviews, and speeds up security questionnaires. That automation matters — running a program on spreadsheets and shared drives is how it weakens.

Validation is a different job. The platform reports on the systems it's connected to; confirming that your live environment matches the documented control — and remediating where it doesn't — takes work the platform doesn't do on its own. The real question isn't whether to keep your platform. It's which systems it doesn't connect to, who verifies the controls it reports, and who fixes what's found. A complete program has all three: a system of record, validation in production, and clear ownership of remediation. Plenty of organizations have the first and assume the other two are handled.

How Emry validates controls where they run

Emry Networks is a managed service provider built around compliance. Where a general IT team measures success by resolved tickets, Emry measures it by managed risk — and that shows from the first engagement. The work runs on the Emry Assurance Roadmap. It starts with Regulatory Discovery, a full scan of your live environment assessed against frameworks including HIPAA, SOC 2, ISO 27001, NIST, PCI DSS, CMMC, and HITRUST, producing a plain-English Risk Status Report that names every gap between documentation and actual systems. Security Hardening then deploys a managed stack — CrowdStrike EDR, managed encryption, secure and tested backups, and managed detection and response — moving the environment from at-risk to defensible. Continuous Management holds the posture with 24/7 monitoring, staff training, and recurring compliance-drift checks. The full sequence is laid out in how it works.

Across our engagements, Emry validates more than 500 controls a year by assessing them directly in the systems where they run. That figure is from our internal records and reflects the real work of verifying configurations rather than reviewing documents. We document every result — and in one case that discipline took a multi-location healthcare group to HIPAA audit-ready status in 90 days, through real operational change rather than a rewrite of the policy set.

If your policies are strong but you can't say for certain that your live environment matches them, that uncertainty is itself a finding. Better to surface it on your terms than to have an auditor — or an attacker — find it first.

Find out whether your controls actually match your binder

We assess your live environment against the frameworks that apply to you, name every gap in plain English, and help you close them — without taking systems offline.

Schedule a consultation

Frequently asked questions

What evidence actually proves a control is operating, not just documented?

System-generated records with time stamps: configuration exports showing a setting is active, audit and monitoring logs retained for the required window, access-review records naming the reviewer and date, restore-test results with recovery times, or tickets linking a finding to its fix. A policy states intent. When an auditor tests whether a control works, they ask for the underlying records and sample them — so you need the actual evidence, not a summary of it.

How is control validation different from a vulnerability scan?

They answer different questions. A vulnerability scan looks for known weaknesses — missing patches, exposed services, weak settings against a technical baseline. Control validation checks whether a specific framework requirement is actually being met in operation: is MFA enabled on these accounts, is logging retained for the required period, is encryption applied where data rests? A scan can feed validation but doesn't replace it. Most control failures aren't vulnerabilities; they happen when systems are configured correctly but no one confirms the requirement is being met.

What does “accurate and thorough” mean for a HIPAA risk analysis?

OCR expects an organization-wide analysis that matches your real environment. Accurate means it reflects your current setup — including cloud services, devices, and vendor connections added since your last review. Thorough means it covers everything, not just the easy parts: every place ePHI is created, received, stored, or transmitted, and how it moves. You then assess threats and vulnerabilities and rank likelihood and impact to prioritize. Most important, the analysis is only step one — OCR's focus has shifted to risk management, meaning what you did about the findings.

Will the updated HIPAA Security Rule be in effect in 2026?

No. The Notice of Proposed Rulemaking was published on 6 January 2025 and the comment period closed on 7 March 2025. As of July 2026 OCR has not issued a final rule or confirmed a timeline, and the proposal could be finalized as written, revised, delayed, or withdrawn. The current Security Rule remains in force and is being actively enforced. Treat the proposal as a signal of direction, not a requirement — and note that most of what it proposes is already expected under the current rule.

If a control changes during a SOC 2 observation period, does that create an exception?

Not necessarily. A SOC 2 Type 2 report assesses whether the control objective was met throughout the period, not whether the configuration stayed frozen. Swapping a tool, threshold, or owner is normal. An exception arises when there's a gap in operation, missing evidence for a sampled point, or a change made without a record. The way to avoid them is to document changes as they happen and keep evidence current, rather than reconstructing it before the audit.

Who owns the compliance evidence — us or our IT provider?

You do. Your organization is the regulated party, so you're responsible for demonstrating compliance regardless of who runs the systems. Two things to confirm before an audit: that your provider can hand you any evidence they hold, in a usable format and on demand, even if you part ways; and that if they're a business associate or service provider, your agreement describes the real data flows and responsibilities rather than a generic template. An MSP can generate and retain the evidence, but accountability stays with you.

Sources

HHS Office for Civil Rights, “HHS' Office for Civil Rights Settles Four HIPAA Security Rule Ransomware Investigations,” press release, 23 April 2026 — settlement totals, affected individuals, investigation counts, and per-entity risk-analysis findings.
HHS Office for Civil Rights, “Risk Management Under the HIPAA Security Rule,” video guidance, 8 April 2026 (Nicholas Heesters) — policies alone are not sufficient evidence of implementation.
Mintz, “OCR Video Emphasizes Ongoing Risk Management Under the HIPAA Security Rule,” 20 April 2026 — legal analysis of the OCR video.
45 CFR §164.308(a)(1)(ii)(A) — HIPAA Security Rule risk analysis requirement.
HHS Office for Civil Rights, HIPAA Security Rule NPRM, Federal Register, 6 January 2025; comment period closed 7 March 2025. Status as of July 2026: proposed, not final.
PCI Security Standards Council, PCI DSS v4.0 / v4.0.1 — 64 new or updated requirements, 51 future-dated to 31 March 2025 (incl. Req. 11.6.1 and 12.3.1).
AICPA, SOC 2 and the Trust Services Criteria — Type 2 reports address suitability of design and operating effectiveness across a defined period.

Every exact figure is attributed to its primary source and reflects the most recent published edition available at the time of writing; regulatory status was verified as proposed-vs-final at publication and may change.