Compliance assessment is one of those jobs where the actual expertise is a small fraction of the effort. An experienced assessor knows within minutes whether a policy document satisfies a control. Getting to that moment takes hours: chasing the document by email, reading two hundred pages to find the four that matter, recording the conclusion in a spreadsheet, and copying the finding into a second spreadsheet where the risks live.

We built Quince Audit because we were doing that work ourselves and the tooling around it was email, Word, and Excel. It is the platform our assessors now run client engagements on, and this note is what it does and why it is shaped the way it is.

The Quince Audit controls register for ISO 27001, with a detail panel showing the requirement text, suggested evidence and two attached evidence files. An AI assessment in Quince Audit proposing a Partial verdict, with a written narrative and two identified gaps listed beneath it. A failed control in Quince Audit showing the assessment narrative and a linked gap ticket with a due date and open status. The NIS2 compliance matrix in Quince Audit, ten controls assessed across twelve services as a colour-coded grid. The EU AI Act matrix in Quince Audit, controls assessed across four AI systems with completion statistics above. A GDPR Article 35 DPIA assessment in Quince Audit for Microsoft 365 Copilot, showing pass, partial, fail and pending counts across twelve controls.
Quince Audit in our demo environment, populated with sample data for a fictional group. Client assessments are never used for illustration.

The problem, stated precisely

Every failure in a manual assessment process is a failure of linkage. The evidence is not linked to the control, the finding is not linked to the evidence, the risk is not linked to the finding, and the report is not linked to any of them because it was written from scratch at the end.

That produces four specific pains, and we built against each one:

  • Clients do not know what to send. The single most common question in an engagement is some version of "what evidence do you actually need?" Answering it by hand, per control, per client, is a tax on every cycle.
  • Assessors read too much. The judgement is fast. The reading is slow, and it is the same kind of reading every time.
  • The same control is assessed repeatedly. An access control requirement in ISO looks a great deal like the equivalent in NIS2. Assessed separately, every time.
  • Conclusions are not reproducible. When a verdict is challenged a year later, reconstructing why an assessor concluded pass is archaeology.

How the assessment is modelled

The design decision that shaped everything else was refusing to treat frameworks as different products.

Some standards are naturally a flat list of controls. ISO 27001:2022 works that way, and so does a GDPR Article 35 DPIA. Others only make sense assessed per service: for NIS2 the question is not whether the organisation has an incident handling process, it is whether each in-scope service does. The EU AI Act behaves the same way, where the services are individual AI systems.

So the platform has two views, a register and a matrix, over one underlying assessment model. A matrix cell and a register row are the same object viewed differently. New standards are added as data rather than code, which is what makes a custom framework, a client's own key-controls list for instance, a configuration task rather than an engineering project.

Where the AI sits, and where it deliberately does not

The assessment engine reads the uploaded evidence against a control and proposes a verdict, a plain-language narrative explaining it, the specific gaps it found, and a suggested risk score.

The AI produces a proposal. An assessor confirms every one of them. It is a first pass, never a decision.

Two constraints on that, both deliberate, and both the kind of thing we would insist on for a client system too.

The assessor confirms everything. An automated compliance verdict is worth nothing to the person who has to sign the report, because they carry the professional responsibility. What saves them time is not being told the answer, it is being handed a structured first read with the relevant passages already found and the gaps already articulated. They then agree or disagree in seconds rather than hours.

The AI output is not shown to the assessed organisation. A draft verdict that an assessor has not yet reviewed is not a finding, and showing it to the client would turn a working note into a statement they would reasonably react to. Clients see their controls, what evidence to provide, and the confirmed outcomes.

The same reasoning we applied to turning the EU AI Act into engineering tickets applies to our own tool: the reasoning behind a judgement is the artifact that matters, not the label.

The chain that makes it defensible

The part we are most satisfied with is not a feature, it is the linkage. A control holds its evidence. An assessment references the evidence it read. A gap ticket is raised from the assessment, carrying an owner and a due date. A risk register entry escalates from the gap and keeps a reference back to the control that produced it.

Pull any thread and you get the whole chain. That is what turns a conclusion into something defensible a year later, and it is why the report at the end can be generated from the assessment rather than written alongside it.

What is live and what is not

Being specific here matters more than being impressive.

Live and in use on engagements: the controls register and the compliance matrix, control detail with evidence, the AI assessment engine, gap tickets with assignment and escalation, the risk register, and the dashboard across engagements. Four frameworks are configured: NIS2, the EU AI Act, ISO 27001:2022, and a GDPR Article 35 DPIA.

Still being built: the client-facing portal where organisations upload evidence themselves, template-driven report generation, the searchable evidence repository with version history, self-service custom standards, and full role-based access control. Three further ideas are designed but not built: AI-suggested evidence that tells a client exactly what to send per control, a cross-standard control map so a pass on one standard grants a preliminary pass on its equivalent elsewhere, and an archive lock that freezes an assessment immutably once the final report is confirmed.

We have no published numbers on hours saved per engagement. We are running assessments on it and measuring, and when we have a figure that survives the sample size and method questions, it will appear here. Until then this note is a description of a tool, not a claim about its return.

Why we build our own tools

There is a commercial argument, which is that owning the platform means no per-seat licence sits between us and a client engagement. That is real but it is not the main one.

The main one is that we sell sovereign machine learning, and a consultancy that recommends clients keep their models and data under their own control while running its own practice on someone else's black box is not making an argument, it is making a sales pitch. Quince Audit runs on infrastructure we control, on the architecture described in our reference architecture note. It is the same bet we ask clients to make, taken with our own business.

If you have a compliance assessment coming up, whether NIS2, the EU AI Act, ISO 27001 or a DPIA, our audit engagements are a package of consultant hours run on this platform. If you are building something similar and want an honest read on the machine learning in it, the ML Feasibility Sprint is two weeks at a fixed price.