Solutions
Move your controls from attested to evidenced — including the ones you do not host.
Assurance built on the distinction that matters: what has been declared, and what has been proven. Extended to the vendor and SaaS estate, where declaration is usually all anyone has.
Software-as-a-service inverts how governance works, and most programmes have not adjusted.
Enterprise standards work on infrastructure you control because you can inspect it. You can query the host, read the configuration, scan the certificate. Vendor SaaS removes that entirely. The environment belongs to someone else, and no amount of internal tooling will tell you how their database is replicated.
The usual response is to send the vendor a questionnaire and file the answers. That is not governance; it is documentation of a claim. And because every provider names their availability constructs differently — availability zones, regions, pods — the answers cannot even be compared to each other, let alone to your own standard.
The three things you genuinely control are the contract, the evidence you require the vendor to produce, and the slice of the configuration that remains yours. A SaaS standard that is not built on those three levers is decorative.
What we build
A standard that survives contact with a vendor estate
Outcome-based requirements
Requirements written as the outcome you need — survive the loss of a fault domain within a stated recovery objective — rather than one provider’s implementation vocabulary. Authored once, applicable to every vendor.
Vendor crosswalk
A translation layer mapping each provider’s availability and resilience constructs onto your neutral model, so that "does this meet our standard" becomes an answerable question rather than a terminology argument.
Evidence pipeline
Audit reports, certifications, bridge letters and disaster-recovery test results ingested, text-extracted and made citable — so a control can climb from attested to evidenced by pointing at a specific page of a specific document.
Anchored to real frameworks
Mapped to the frameworks your auditors and vendors already speak — SOC 2, ISO 27001 and its cloud extensions, CSA’s control matrix, and sector anchors such as HITRUST where regulated data is involved. We do not invent a private taxonomy.
The slice you still own
Configuration baselines for the part of a SaaS tenancy that remains your responsibility — identity federation, privilege model, logging, data loss prevention — assessed the same way as anything you host.
Repeatable reconciliation
Estate discovery from federation logs, procurement records and inventory, baselined against the standard and re-checked on a cadence, so reconciliation is a standing posture rather than a one-off audit exercise.
What changes
What this changes
A defensible answer about the vendor estate
You can state, per vendor application, which requirements are met, on what basis, and when that basis expires. For most organisations this is the first time that sentence has been possible.
Attestation stops being the ceiling
Vendor evidence that already exists — a disaster-recovery test report sitting unread in a records platform — reliably moves critical controls up the ladder. The gain is often in reading what you have, not in demanding more.
Findings become owned decisions
Where a requirement cannot be met, it becomes a risk acceptance with a named owner and an expiry date rather than an open finding that ages indefinitely.
The procurement gate acquires teeth
Requirements, required evidence and standard contract language arrive before signature, which is the only point at which a vendor has any commercial reason to agree to them.
On internal platforms
Your own as-a-service platforms are a different case: you still own the environment, so inspection still applies. What changes is that tenant isolation, noisy-neighbour behaviour and the platform’s own resilience become inherited controls for every application running on it — assessed once, applied to many.
How much of your control coverage is evidence?
It is a short exercise to find out, and the answer usually determines where the next year of assurance work should go.