What auditors actually ask for, and why your green checkmarks lie

My first audit, I built a binder.

An actual physical binder, with tabs, because I had convinced myself that the auditor would want to see the depth of our thinking. She spent about four minutes on it, then asked me for a list of every person who had left the company in the previous twelve months and the date each one's access was revoked.

I did not have that list. I had a beautiful binder.

That's roughly the shape of every audit conversation I've had since. The things you're proud of get skimmed. The unglamorous operational seams get inspected in detail, because that's where organizations actually fail, and auditors know it long before you do.

If you've just been handed your first audit and you're privately panicking, most of what follows is the stuff I wish somebody had told me before the binder.

Nobody is doing this for security

Let's be blunt about why this is on your desk at all.

Almost all compliance work exists to enable sales. SOC 2 Type 2 is the baseline you need to sell in the US. ISO 27001 is what you need to sell into the EU. CMMC and StateRAMP function as supplements when you're selling into jurisdictions with their own control sets. The security benefit is real and secondary. The forcing function is a procurement checkbox at a company you want money from.

Once you accept that, a budget lever appears that almost nobody uses.

Take your security questionnaire responses, the due-diligence questionnaires that come in with every enterprise deal, and map them to closed deals and annual recurring revenue. One team did the arithmetic and found that answering a questionnaire well made a deal roughly eight times more likely to close. Eight times. That converts your security tooling from a cost center into a revenue-attributable line item, and it is dramatically easier to get funding for something the sales org can see itself in.

I sat on that idea for years because it felt like a marketing trick. It turns out to be the first honest description of what this work is actually for.

Three words that mean three different things

Most audit confusion comes from a vocabulary collision, and untangling it takes about ninety seconds.

Framework is the abstract requirement. "You must have a password policy." That's it. No detail, no numbers, deliberately non-specific.

Policy is how your organization implements that requirement, in writing. Your actual document, with your actual minimum length and rotation rules.

Controls are the technical or process proof that the policy is being followed. The MDM configuration, the report, the ticket, the screenshot.

The trouble is that "control" and "policy" get used at all three layers by different people in the same meeting, which is how scope negotiations turn into forty-minute misunderstandings. When somebody asks whether you have a control for something, find out which layer they mean before you answer.

Here's the part that makes the whole thing tractable: roughly 80% of controls are shared across SOC 2, CMMC, StateRAMP, and ISO 27001. You are not building four programs. You are building one and re-presenting it. And these documents are much smaller than their reputation suggests. A FedRAMP control set, actually read cover to cover, runs about 15 pages. I recommend reading it. It takes an afternoon and it permanently changes how you talk to auditors.

How strict is strict depends entirely on the framework

This is where people get burned, because they assume all frameworks are equally prescriptive. They are not, and the gap is enormous.

SOC 2 will let you define your own vulnerability remediation SLA window. Genuinely your own. As long as it's documented and you follow it, you set the number. That's a gift, and it means the correct move is to pick a window you can actually hit rather than the one that sounds impressive.

CMMC, StateRAMP, and recent CIS guidance are far less generous. Some of that guidance pushes remediation to as little as 3 days from disclosure of a CVE. StateRAMP windows commonly land in the 7 to 14 day range.

The hardest one I know of is UK Cyber Essentials Plus, which requires every application patched within 2 weeks, fleet-wide. That sounds achievable until you count your applications. Most patch-management catalogs cover only a fraction of what's actually installed in a real environment, in one case roughly 300 apps out of more than 1,000 present on the fleet. The remaining 700 are not covered by anything, and the control says all.

If you're staring at a requirement like that, start with your application inventory rather than your patch coverage percentage. You cannot negotiate about a gap you can't measure.

The single best tactic in this entire article

Negotiate a pre-audit with the same firm three to four months before the real audit.

That's it. That's the whole thing.

You walk them through your interpretation of every piece of ambiguous language, you argue about scope while the stakes are zero, and you get their agreement in writing. "Resolve vulnerabilities in a reasonable time" is a sentence that will cost you a week of stress during a live audit and twenty minutes during a pre-stage review.

Then the real audit becomes an administrative exercise, because the hard arguments already happened, with the same people, on a day when nobody was going to fail.

A companion piece of advice that sounds cynical and isn't. During a live audit, answer only the specific question asked.

Not because you're hiding anything. Because volunteering adjacent detail is how you surface a control violation the auditor was never going to find, in a context where you have no time to remediate it, in front of somebody whose job is to write it down. Answer the question. Fully, honestly, completely. Then stop talking.

I've watched a well-meaning engineer turn a clean audit into three findings in about ninety seconds of enthusiastic over-explanation. He was being helpful. It cost the company a quarter of remediation work.

Why your green checkmarks lie

Here's the failure mode you should assume is already happening in your environment.

Automated GRC platforms implement controls far more loosely than your written policy does. The tool checks "user has a password manager." Your policy says "users must use the organization-sanctioned, centrally managed password manager." Those are different sentences with different meanings, and the tool cannot tell them apart.

So a user installs a personal password manager, the platform turns green, and your control is failing. Nothing in your dashboard will ever tell you. It surfaces on audit day, in front of the auditor, and if it happens more than once or twice you have a much bigger problem than one finding, because you've taught the auditor that your dashboards can't be trusted and now everything gets sampled by hand.

There's a structural version of this worth naming. Some platforms will write your policy, enforce it, validate it, generate the evidence, and help you select the auditor. When one system does all five, it's fair to ask what is actually being validated. My rule: keep enforcement tooling and evidence-collection tooling on separate systems. It's mildly inconvenient and it's the difference between a control and a story about a control.

Feed the telemetry somewhere it will keep. MDM platforms are excellent at reporting current state and terrible at history.

Ask your MDM what percentage of the fleet was patched to a given version six months ago. It cannot tell you. It knows today. That question, in almost exactly that phrasing, is what an audit asks for, because auditors care about whether you operated the control over a period, not whether it's true this afternoon.

So push device telemetry daily into something that keeps it: a SIEM, a data lake, or even your ticketing system. Daily snapshots, retained. This is a small pipeline that saves you an ugly conversation later, and it is the one architectural recommendation in this article that I'd implement before anything else.

What to have ready before the first auditor call

None of this is exotic. All of it is stuff people scramble for at the worst possible moment.

1. A leaver list. Every departure in the audit period, with the date access was revoked and by whom. Contractors included. Especially contractors.
2. A joiner list. Every onboarding, with the date access was granted and evidence of approval.
3. Your written policies, dated, with a version history. Not a wiki page somebody edited last Tuesday.
4. Your documented SLA windows, especially for vulnerability remediation, and evidence you met them.
5. A device inventory with last-check-in dates. Sort ascending and look at the top. That is what the auditor will do.
6. Your list of deviations, with rationales. Risk-based deviations from a benchmark default are sanctioned, not embarrassing. Allowing AirDrop, raising a failed-login threshold from 5 to 10, retaining audit logs 30 days instead of 60. Write each into the generated documentation with a written reason so the auditor can see the choice was deliberate.
7. A short, honest list of exemptions. Exemptions are for a handful of genuinely impossible cases, like a virtual machine that can never pass a wake-on-LAN check. An exemption still logs as a failure in the audit trail; it's just excluded from your pass rate. They are not a substitute for tailoring, and a long exemption list reads exactly like what it is.
8. Historical evidence, and not only current state. See the previous section.

Worth knowing before you dread it: a large fraction of compliance work is documentation generation rather than new technical control. The tooling in this space can auto-produce auditor-formatted packages in PDF, HTML, Excel, JSON, and markdown. A request that used to eat an afternoon of copy-paste turns around in about five minutes. If you're spending hours assembling evidence by hand, you're doing a job that a generator does better.

Where to actually spend your process time: device recovery, onboarding, and offboarding.

Not because they're technically hard. They're the easiest things in this article. They're where findings come from, because they depend on other departments remembering to tell you something.

Contractor offboarding is the single most common real SOC 2 finding I'm aware of. The pattern never varies: the contractor stops working, HR never triggered a workflow because the contractor was never in the HR system, IT never hears anything, and the laptop sits unreturned and unmanaged. Then an audit surfaces a device that hasn't checked in for two years and somebody has to explain, in writing, where it is.

You will not solve that with better tooling. You solve it with a recurring conversation with whoever signs contractor agreements.

One last thing, for whoever on your team wants a promotion

Give the next audit cycle to a junior person and make them the named owner.

The outcome is already largely determined by prep work you did months earlier, which means the risk is low and the credit is real. "Led our SOC 2 audit" is a concrete, verifiable accomplishment, and those are genuinely hard to manufacture for someone three years into their career. Most of what juniors get to put on a promotion case is participation in things other people owned.

Which is the part of compliance I've come to actually like. Stripped of the binder and the panic, it's a forcing function that makes an organization write down how it works and then prove it does that. Most teams have never done either. The auditor is just the first outsider who ever asked.

That question is worth answering well, even for the ones who never ask.

---

Foqal keeps IT requests, approvals, and their records in Slack and Microsoft Teams, which turns out to matter when someone asks you to prove what happened six months ago.