The Missing Compliance Artifact Wasn't Another Policy

There’s a slightly awkward stage in the life of a SaaS company where compliance stops being some distant enterprise concern and starts showing up in ordinary business conversations.

A larger prospect asks a few security questions. Procurement wants to know how suppliers get reviewed. Someone mentions ISO 27001. A customer wants actual evidence, not reassurance. A partner asks whether there’s a real process behind the policy PDF.

The instinct at that point is usually to start creating things — another policy, another checklist, another spreadsheet, another folder called something like ISO-final-final-v2.

I’m not convinced that’s the right first move, though.

Most small and growing SaaS companies aren’t starting from zero. They already have a strange, uneven pile of useful material lying around — an incident playbook, some access-control notes, a disaster recovery test, a vendor list, vulnerability summaries, management notes, maybe a few documents that got created during an earlier customer review.

So the harder question isn’t what document should we create next. It’s what does the material we already have actually prove? That distinction sounds small, but it changes the whole workflow.

A fictional SaaS company with a very normal problem

To make this concrete, I used a fictional company called AcmeFlow.

AcmeFlow is a small B2B SaaS company with 35 employees and EU customers. It runs a cloud-hosted workflow product, and — like most real companies — has gradually accumulated some operational and security documentation just by responding to normal business pressure over time.

Before any formal readiness work, AcmeFlow already had nine documents on hand: an ICT Risk Management Procedure, an Incident Response Playbook, a Business Continuity and Disaster Recovery Test Report, a Third-Party ICT Provider Register, an Access Control and Joiner-Mover-Leaver Procedure, a Security Monitoring and Logging Runbook, a Vulnerability Management Summary, Management Review Notes, and an AI Feature Inventory and Governance Note.

None of it was built as some perfectly designed ISO 27001 package — and that’s intentional. Real companies rarely wake up one morning with a beautifully curated evidence set. Documentation grows around incidents, customer questions, operational needs, security work, procurement, engineering habits, and whatever happened to be urgent that quarter.

What I actually wanted to know first wasn’t whether AcmeFlow could generate more documents. It was whether the nine it already had were telling us something useful.

Start with a baseline, not with document generation

I ran an ISO 27001 readiness assessment in AlturaQuantera against the evidence AcmeFlow already had.

The initial result came out at 70% across the 30 readiness controls in this assessment — 12 controls marked Met, 18 Partially met.

Honestly, I don’t think the percentage itself is the interesting part. A readiness score is a summary — useful for orientation, but not something I’d trust blindly, especially in an AI-assisted workflow. What matters more is whether the reasoning underneath it holds up, and whether every conclusion can actually be traced back to something real.

The baseline did make one thing clear right away: AcmeFlow wasn’t “non-compliant because it only had nine documents.” Some controls were already well supported. Others had relevant material sitting there, just not quite enough to show the underlying process was actually running. That second group is where it gets interesting.

One supplier register, two different conclusions

The clearest example was supplier security.

AcmeFlow already had a fairly detailed third-party ICT provider register — AWS, Microsoft Entra, GitHub, PayPro Global, OpenAI, SupportDeskCo, PagerDuty, each with an owner, a criticality rating, a review status, data categories, and any open issues.

For one control, that turned out to be enough: Critical suppliers are identified — Met.

Which makes sense, intuitively — the evidence can answer fairly concrete questions like who the important suppliers are, which services they support, which ones sit at High or Medium criticality, who owns each relationship, when it was last reviewed, and what’s still open. AcmeFlow could clearly show it knew which third parties actually mattered.

But the neighboring control told a different story: Supplier security process exists — Partially met.

This, to me, is the more useful distinction than either score on its own. A register can show that suppliers have been identified and classified. It doesn’t automatically show that a repeatable supplier-security process is actually operating end to end. The assessment found real signs of activity — but also loose ends: an overdue DPA and retention review, pending access-review evidence, an exit strategy that had never been fully tested, and a handful of other supplier-specific follow-ups.

In other words, AcmeFlow had inputs, and fragments of a process. What it hadn’t yet shown clearly was the full loop — review, decision, owner, due date, remediation or risk acceptance, follow-up. That’s a very different gap from “we need a supplier policy.”

The temptation to solve every gap with another policy

This is where compliance work can quietly work against itself.

A system flags a process as incomplete, so someone writes a new document describing the process. The document might be perfectly reasonable — it might even use all the right words. But the original question was never really whether the company could describe a supplier-security process. It was whether the company could show the process had actually run.

There’s a real difference between writing “we review important suppliers annually,” and being able to point to the September supplier review — which providers got reviewed, what was found, which owners accepted which actions, what the due dates are, and which residual risks the company decided to carry. The first is documentation. The second is evidence the thing actually happened. A mature compliance system needs both, but mixing them up produces a lot of paperwork that feels reassuring without making the underlying process any more trustworthy.

Asking for the smallest useful next step

Instead of immediately generating a policy, I used the built-in AlturaQuantera’s AI copilot to push back on the finding — deliberately asking for the minimum effort path: what’s the smallest concrete action that would move the supplier-security process toward Met, without creating unnecessary documentation?

The useful answer wasn’t “write a better supplier policy.” It was to add evidence that a supplier review had actually been completed, with explicit outcomes attached.

So rather than write a separate completion note for one supplier, I added a short Supplier Security Review Record — Q3 2026, covering the High and Medium criticality suppliers already in the register. It was deliberately boring — and I mean that as a compliment. It contained the review scope, the review criteria, the outcome-handling rule, the approver, the review date, and one row per supplier with the outcome, owner, open action or decision, and next review date.

The point wasn’t impressive prose. It was leaving a trace that the process had actually been executed. AWS got an exit-strategy test scheduled. Microsoft Entra had access-review evidence attached. GitHub had a security exception formally accepted with a review point set. SupportDeskCo had its DPA and retention work reviewed and tracked. A few other suppliers had their own outcomes and next actions — some issues stayed open, and that was fine. A functioning process doesn’t need every supplier to be perfect. It needs open issues to be visible, owned, decided, and followed through.

One new artifact changed the evidence story

After adding the review record, I reran the same readiness assessment. The supplier-security control moved from Partially met to Met — and more importantly, the reasoning behind it changed for a sensible reason. The assessment now saw the process actually in use across multiple High and Medium suppliers, with outcomes tracked, owners assigned, due dates set, and residual risks accepted where necessary. The new Q3 review record showed up as the most relevant evidence for the control.

That’s really the part of this whole experiment I care about. The missing piece was never another policy. It was evidence that the process had actually run.

Compliance evidence isn’t the same thing as compliance documentation

Written down like that, it sounds obvious. In practice, the two get mixed together constantly.

A policy tells you how access reviews are supposed to happen; an access-review export, an approval record, a remediation ticket show that they actually did. A business continuity procedure describes recovery expectations; a recovery test report shows what happened when the company actually tried to restore a system. A supplier-security policy defines annual review expectations; a supplier review record shows which providers got reviewed, what was found, and what happened next. The documents are related, but they do different jobs — one describes intent, the other leaves a trail of what actually occurred — and readiness work gets a lot more useful once it can tell the two apart.

This also changes how I think about AI in compliance products

“AI for compliance” can collapse pretty easily into text generation — upload some context, ask for an Information Security Policy, get back several pages of plausible prose. That’s useful sometimes, and it’s why AlturaQuantera has policy generation built in. But generating text isn’t really the hard part anymore.

The harder problem is keeping an honest relationship between what the company says it does, what the evidence actually shows it did, what a framework expects, what’s still missing, and what should happen next. That’s a much more interesting product problem than “ChatGPT with compliance templates” — and it demands some restraint, too. An AI-assisted readiness result shouldn’t be treated like an auditor’s verdict or a certification decision. Models can misread evidence, classification can drift, and a score can end up looking far more precise than the judgment underneath it actually is.

That’s why I care a lot more about traceability than about pretending the number is authoritative. Can I see why a control was marked this way? Can I inspect the evidence behind it? Can I push back on the conclusion, add better evidence, and reassess — and does the explanation actually change in a way that makes sense? Those questions matter more to me than whether the dashboard says 70%, 74%, or 81%.

The first useful question is often “what do we already have?”

I think a lot of SaaS teams start their compliance work one step too late — with “what do we need to create?” A better starting question is usually “what do we already have, and what does it genuinely demonstrate?”

That question tends to produce a more honest map. Some existing documents turn out stronger than expected. Some turn out to be background context rather than real evidence. Some controls genuinely need new documentation. Others need something a lot less glamorous — a completed review, an approval, an owner, a test result, a decision record, or proof that an open issue was actually followed through to closure.

That’s the kind of workflow I’m building AlturaQuantera around. Not “generate a compliance pack and declare victory,” but something closer to: existing material, turned into evidence, turned into an assessment, pointing at a specific gap, leading to a practical action, producing new evidence, and then reassessing.

It’s a less magical story. I think it’s also a much more useful one.

You can see AlturaQuantera here.