The evidence comes out of the platform,
not out of a spreadsheet
Assessors do not ask what your dashboard said. They ask how you know, and they want the request, the response and the date. We map your estate to the framework you are being asked about, evidence what can be evidenced, and are specific about the rest.
Three things we cannot do for you
Said before the sales pitch rather than after it, because this is where a buyer is most likely to spend money on the wrong thing.
We cannot certify you and neither can anyone who audits you — that separation is the point of it. We get you ready, and we tell you what the assessor will ask.
Policies, training, suppliers, contracts and governance are the bulk of every one of these. We cover the estate; you will need somebody for the rest, and we will say so on the first call.
Assessors ask how you know, not what your dashboard said. Everything we produce carries the request, the response and the date, which is what makes it evidence.
One square per control. Count the empties.
Filled where a cloud audit produces the evidence, hairline where it does not. The empty squares are the controls that are yours to prove some other way, and knowing how many there are is the difference between being ready and being surprised.
The international standard for an information security management system. Annex A carries 93 controls; a cloud audit speaks directly to the technological ones.
Annex A evidence mapped control by control, with the gaps written as findings your team can close before the certification body arrives.
The report North American customers ask for. Trust Services Criteria, tested over a window rather than on one day.
Evidence against the Common Criteria your platform is responsible for, in the form your auditor expects, plus the control descriptions to go with it.
Required if you touch card data. Prescriptive, technical, and unforgiving about scope — most of the work is proving what is out of it.
Cardholder data environment scoping, segmentation testing, and the technical requirements evidenced with configuration rather than with assertions.
Article 32 asks for security appropriate to the risk. What "appropriate" means is decided after something has gone wrong, which is the wrong time to work it out.
A technical measures record you can attach to your ROPA, plus the personal data we found in places your privacy notice does not mention.
Consensus configuration baselines per provider. Not a certification — the yardstick underneath most of the others.
A full benchmark pass per account with every exception documented and argued, rather than a pass rate with no story behind it.
Sector obligations and the UK government scheme. Both are increasingly a condition of the contract rather than a nice-to-have.
A readiness position against each, with the technical gaps costed so you can decide what to fix before you decide what to certify.
Audit first, certify second
Doing it the other way round is how a business ends up certified against a standard while a build container can still read the production database. Both things can be true at once, and one of them is the one that costs you customers.
We start from your estate rather than from the standard, so the mapping reflects what you actually run instead of what the diagram says.
Findings are prioritised by risk, not by clause. A Critical that appears in no framework still gets fixed first, and we will argue for that.
Where the evidence can be produced by a query rather than a screenshot, we set that up, so the next audit costs your team days instead of weeks.
You go into the assessment knowing what will be asked and what the answer is. Nothing about the day should be a surprise.
Send us the questionnaire you have been asked to fill in.
We will tell you which of it your estate can answer today, which of it needs work, and which of it is not a technical question at all — in writing, on one page, before anything is signed.