California's new CCPA cybersecurity audit regulations took effect January 1, 2026 — and the California Privacy Protection Agency has already started issuing fines: $1.35 million against Tractor Supply, $632,500 against Honda, $345,178 against Todd Snyder. The CPPA's newly formed Audits Division is now conducting both announced and unannounced compliance audits. On the federal side, OCR is in active HIPAA enforcement following the 2025 Security Rule update expected to finalize this year.
Regulators have finished rulemaking. They're in enforcement mode now. If you've been saying "we'll get to compliance soon," soon has arrived.
The 30-day playbook below works whether you're facing a SOC 2 Type 2 audit, ISO 27001 surveillance, a HIPAA OCR review, GDPR regulatory inquiry, or CCPA examination. The specific evidence changes. The preparation structure doesn't.
Before the clock starts: understand what you're being audited against
The single biggest mistake in audit prep is treating it as a document collection exercise before understanding what the auditor will actually test. Different audit types have fundamentally different scopes.
| Audit type | What auditors examine | Observation period? | Who audits |
|---|---|---|---|
| SOC 2 Type 1 | Design of controls at a point in time | No | Licensed CPA firm |
| SOC 2 Type 2 | Controls operating effectively over 6-12 months | Yes — 6-12 months | Licensed CPA firm |
| ISO 27001 | ISMS scope, Annex A controls, management review | No (initial), yes (surveillance) | Accredited certification body |
| HIPAA (OCR) | Policies, risk analysis, BAAs, workforce training | No — point in time | Office for Civil Rights |
| GDPR (regulator) | Privacy notices, data subject rights, processing records | No — point in time | Data Protection Authority |
| CCPA (CPPA) | Privacy policy, opt-out mechanics, cybersecurity controls | No — point in time | California Privacy Protection Agency |
| PCI-DSS QSA | Cardholder data environment controls, network segmentation | No | Qualified Security Assessor |
Point-in-time audits are prep-intensive: you need everything in order by the audit date. Observation period audits (SOC 2 Type 2, ISO 27001 surveillance) require you to have been operating controls correctly throughout the period — not just on day one. If you're 30 days out from a Type 2 audit completion, you're not preparing for the audit; you're cleaning up the record from the past year.
If your audit observation period is currently running, the 30-day playbook covers what you can still fix before the period ends. It doesn't retroactively fix evidence gaps from earlier in the period. Auditors will ask for evidence from throughout the observation window — a clean final month doesn't erase sparse evidence from months 2-5.
Week 1 (Days 1–7): Document gap analysis
Most audit failures trace back to documentation problems — not technical security failures. Policies that reference controls that no longer exist. Privacy notices missing required GDPR Article 13 elements. HIPAA security policies that describe addressable safeguards without implementation decisions documented. An access control policy that says "MFA is required" when half your SaaS tools don't have it enforced.
Week 1 is entirely about finding these gaps before an auditor does.
Document inventory
Compile every compliance-relevant document your organization has. Don't try to decide during this step whether documents are good or bad — just collect them. This includes:
- Information security policy (and any sub-policies: access control, incident response, change management, etc.)
- Privacy policy / Notice of Privacy Practices
- Data processing agreements and business associate agreements
- Acceptable use policy
- Vendor and third-party risk policy
- Risk assessment or risk register
- Business continuity and disaster recovery plans
- Vulnerability management policy
- Asset inventory
- Any prior audit reports, penetration test results, or risk assessments
If documents are scattered across Google Drive, SharePoint, Notion, and someone's desktop, this step alone takes a full day. That's fine — find everything before evaluating anything.
Automated document gap analysis
Once you have your documents collected, run them through a compliance checker against the specific frameworks you're being audited against. Manually cross-referencing a 40-page information security policy against ISO 27001's 93 Annex A controls, HIPAA's 75 implementation specifications, and SOC 2's five Trust Services Criteria simultaneously is genuinely painful — and humans miss things.
PolicyAudit scans your documents against 13 frameworks and shows you exactly which requirements your documents address and which ones have gaps. Upload your information security policy, your privacy notice, your incident response plan, and your BAA template. Within minutes you have a framework-by-framework gap report — which is a much better starting point than reading 300 pages of framework documentation yourself.
Keep a running gap list as you go. For each gap, note: which document is missing the requirement, which framework requires it, and whether it's a missing element (easy to add) or a material policy failure (needs real work).
Technical control inventory
Documentation compliance and technical control compliance are two separate problems. Your policies say what you do; your systems have to actually do it. Walk through the framework's control requirements and map them against your actual environment:
- Access management: Is MFA enforced on every system that your policy says it's required on? Do you have current access reviews documented?
- Encryption: Is data encrypted in transit and at rest everywhere your policy claims?
- Logging and monitoring: Are the logs your policy references actually being retained for the required period?
- Vulnerability management: Is your scan cadence matching what your policy says — and are the results documented?
- Vendor management: Do you have signed agreements (BAAs, DPAs) with every vendor your policy says requires them?
- Training records: Does your workforce training documentation cover the people your policy says need to be trained?
Every gap between "policy says" and "system does" is a potential audit finding. Some are quick fixes. Some are not. Week 1 is about making the list so you can triage in week 2.
Find your documentation gaps before the auditor does
PolicyAudit scans your policies, privacy notices, and security documents against GDPR, HIPAA, SOC 2, ISO 27001, PCI-DSS, CCPA, NIST, and 6 more frameworks simultaneously. Free for up to 3 documents — no credit card required.
Scan your compliance documents for free →Week 2 (Days 8–14): Remediation — fix what you can
Not every gap can be fixed in 30 days. A missing risk assessment that should have been completed annually for the past three years isn't something you can backdate into existence. What you can do is triage: fix the documentation issues immediately, address technical gaps that are quick wins, and document a remediation plan for anything that takes longer.
Documentation remediation (the quick wins)
Most documentation gaps are addable elements — your privacy policy is missing a "How to contact us" section required under GDPR Article 13(1)(a), or your information security policy doesn't address physical security even though ISO 27001 Annex A requires it. These take hours to fix, not weeks.
Work through your gap list from week 1 and update documents starting with the framework you're actually being audited against. Don't try to make every document satisfy every framework simultaneously — you'll spend all your time on documents and none on evidence. Fix the frameworks in scope first.
Version-control your updated documents with a clear date. Auditors often want to see document version history — a policy updated two weeks before an audit raises fewer questions than one updated the day before.
Technical quick fixes and documentation of exceptions
For technical gaps that can be addressed quickly — enforcing MFA on a SaaS tool your policy says requires it, getting a missing BAA signed with a vendor, completing outstanding access reviews — do them now and document when they were completed.
For gaps that can't be fixed before the audit, document them formally. A risk acceptance memo — "We've identified that X control is not yet implemented; here's our timeline and compensating control" — is far better than an undocumented gap an auditor discovers. Auditors aren't looking for perfection; they're looking for evidence that you understand your risk posture and are managing it deliberately.
Pretending a gap doesn't exist, or scrambling to paper over it right before the audit, tends to make findings worse — not better.
Week 3 (Days 15–21): Evidence collection and organization
Evidence is the other half of every compliance audit. Your documents describe what you do. Evidence proves you actually did it.
Pull your evidence package
The specific evidence an auditor will request depends on the framework, but most audits require some version of the following. Start gathering:
- Access control evidence: User access lists for critical systems, access review records, offboarding confirmation for employees who left during the observation period, MFA enrollment reports
- Change management: Change tickets or commit logs showing that changes to production systems followed your documented change management process
- Security monitoring: Log retention confirmation, security alert records, incident response logs (even if no incidents occurred — "no incidents this period" should itself be documented)
- Vulnerability management: Scan reports with dates and remediation timelines, penetration test results, patch deployment records
- Training: Security awareness training completion records with dates, covering all required personnel
- Vendor management: Current signed BAAs or DPAs, vendor risk assessment records
- Business continuity: DR test results or tabletop exercise records
If you use a compliance platform like Drata or Vanta, pull automated evidence exports now. Most platforms generate audit evidence packages directly — don't wait for the auditor to request them one by one. Have them ready.
Organize by framework control
Evidence that exists but can't be found quickly during an audit is evidence that doesn't help you. Organize everything by the framework control it satisfies — not by the tool or system it came from.
A simple folder structure works: top-level folder per framework, sub-folders per control category. Label each piece of evidence with the control ID it addresses. When an auditor asks "Can you show me evidence that CC6.1 (logical and physical access controls) is operating?", you hand them a folder, not a half-hour search through Slack and Google Drive.
Identify any gaps in your evidence package — periods where controls should have been operating but you have no records. Investigate whether the evidence exists and was simply not collected (recoverable) or whether there's a genuine gap in control operation (not recoverable, document as a finding).
Week 4 (Days 22–30): Pre-audit review and dry run
Internal walkthrough
Do a structured walkthrough of your evidence package against the audit scope before the auditor does it. For each control in scope, ask: Do we have a policy that describes this control? Do we have evidence that it operated throughout the observation period? Does the evidence match what the policy says we do?
This walkthrough surfaces the alignment issues that pass initial review but fail under scrutiny — the policy says quarterly access reviews, but the evidence shows reviews ran twice in 12 months. The policy says vulnerability scans run weekly, but the scan reports are monthly. Fix or document these before the auditor asks.
Auditor prep and logistics
Confirm the audit scope, schedule, and evidence format with your auditor or audit firm. Most experienced compliance teams have an evidence request list (sometimes called a PBC list — Prepared by Client) that the auditor provides in advance. Go through it line by line and confirm you have each item ready.
Designate a single point of contact who will handle auditor communication and evidence requests. Auditor questions routed to five different people with inconsistent answers create unnecessary friction. One person who knows where everything is and can speak to your compliance program coherently is worth more than a room full of subject matter experts who contradict each other.
Brief the relevant members of your team on what the audit covers, who might get asked questions, and what to say (and what not to say). "I don't know, let me check with our compliance lead" is always the right answer when someone isn't sure.
Common audit failures and how to avoid them
After going through this process across multiple frameworks, certain failure patterns repeat. Here's what to watch for:
The documentation-reality gap. Your policy says one thing; your environment does another. MFA required by policy, not enforced in practice. Quarterly access reviews required, running annually. This is the most common finding across every framework. Fix it by comparing your policies against your actual configurations before the audit — not during.
Incomplete observation period evidence. SOC 2 Type 2 and ISO 27001 surveillance auditors will ask for evidence from throughout the observation window, not just the most recent quarter. If your vulnerability scan program only started running consistently six months ago but your observation period is twelve months, you have a gap. Know your gaps before the auditor maps them.
Undocumented exceptions. Some controls have legitimate exceptions — a legacy system that can't support MFA, a temporary access grant that was supposed to be revoked. Undocumented exceptions become audit findings. Documented exceptions, with an approval record and a compensating control, often don't. Document everything, including the things that aren't perfect.
Missing vendor agreements. One of the most consistently overlooked areas. If your data processing agreement template is solid but you have three SaaS vendors processing personal data without signed DPAs or BAAs, those are real findings that are easy to prevent with a vendor review before the audit.
Stale risk assessments. Most frameworks require annual risk assessments. If yours was last completed 18 months ago, update it before the audit. Risk assessments that predate significant changes to your environment (cloud migration, new product line, major workforce changes) will draw auditor attention.
Don't backdate documents, manufacture evidence, or create policies that claim controls were in place before they were. This isn't just an audit failure — it's the kind of thing that turns a compliance finding into a fraud allegation. Regulators and auditors are experienced at recognizing freshly-created documentation. Be honest about gaps and document them properly instead.
The short version
Thirty days is enough to get organized, find your gaps, fix what's fixable, and go into an audit with a clear picture of where you stand. It's not enough to build a compliance program from scratch or retroactively fix an observation period that's already been running.
Start with your documents — that's where most audit findings originate. Run them through PolicyAudit to see where you stand against the specific frameworks in scope. Fix the documentation gaps, organize your evidence, and walk through the complete package before the auditor does. The companies that struggle in audits usually aren't the ones with the worst security programs — they're the ones that haven't organized their evidence and found their own gaps first.
Start your audit prep with a free compliance document scan
PolicyAudit checks your policies and privacy documents against 13 compliance frameworks — SOC 2, ISO 27001, HIPAA, GDPR, CCPA, PCI-DSS, NIST, and more. Upload your documents and see exactly where your gaps are before the auditor does. Free for up to 3 documents.
Scan your compliance documents for free →