Skip to content
NGARi

NGARi · Sovereign security & compliance

Bring the evidence engine to the data.

A compliance programme rarely fails on the framework. It fails on the evidence — scattered across clouds, stale by the time the auditor asks, or legally unable to leave the jurisdiction it was created in. For a defence supplier holding Controlled Unclassified Information, or a client under a data-residency regime, sending that evidence to a multi-tenant compliance platform is not a preference problem; it is the blocker. So the engine arrives instead. Read-only collection on hardware the client owns, and only the assertion travels.

On-premises · read-only connectors · declared policy, not a learned model · no certification claimed · no client system has ever been contacted

0 bytesleaving the client boundary
GET onlyevery connector is read-only
Declaredacceptance policy, versioned
Recomputedhash-chained evidence ledger

Compliance does not fail on the framework

It fails on three things, and every readiness programme eventually meets all three.

Evidence sprawl

An access review lives in an identity provider, a change record in a ticketing system, a scan result in a scanner, a training certificate in an LMS. Each one is a different login, a different export format and a different freshness. Assembling them by hand is where the quarter goes.

Residency and CUI

Some buyers cannot send evidence to a shared cloud at all. Controlled Unclassified Information under a defence contract, data under a residency statute, and US technical data under export controls are three different reasons the same architecture is disqualified.

Point-in-time proof

An audit asks whether a control operated throughout a period. A screenshot taken the week before fieldwork does not answer that, and it cannot show that a control which worked last quarter quietly stopped.

What the engine does

Five things, all deterministic, all readable by a security lead without trusting a model. Every one of them runs on the appliance, inside the client's own boundary.

Read-only evidence collection

Adapters read configuration, identity, ticketing, endpoint, scanner, training, HR and monitoring sources. Every adapter is GET-only by construction — no write, update or delete verb exists anywhere on them, and a guard test asserts it. An evidence collector that can change the system it is auditing is not a collector.

One control set, three frameworks

A declared crosswalk maps each control across SOC 2 Trust Services Criteria, ISO/IEC 27001:2022 Annex A and NIST SP 800-171, so evidence is collected once and asserted three times. Coverage is reported honestly, and a reference that does not exist in the framework catalog is flagged as a defect rather than counted as coverage.

A versioned evidence-acceptance policy

Every evidence item is tested against a declared policy: source allowed, type accepted, still current, properly classified, approved, and carrying information. The outcomes are permit, refuse and needs_human — and the default is refuse. Refusal is a decision with a code and a reason, never a silent drop.

Controls tested over a period

A control is called effective only when every evidence type it requires is admissible and the admitted items meet a declared period minimum. A single point-in-time export cannot support a period assertion, so it returns insufficient — no evidence and no observations are never promoted to a pass.

Drift between periods

The engine re-runs the same policy over a baseline and a recent period and reports the controls that regressed or improved. A control that was effective and is no longer is exactly what a point-in-time audit cannot see.

Evidence that re-verifies itself

Every stage is written to a hash-chained ledger, and the receipt is rendered from the ledger rather than written alongside it — so the record cannot disagree with its own evidence. Signed only when a key is configured, and it says so when it is not.

The honest line

There is no trained model and no weights in this engine. It is a deterministic reference implementation of the analysis loop, tested against a synthetic control fixture. It has never seen a client's security evidence, no cloud account, identity provider, scanner or auditor has ever been contacted, and nothing about real audit effort has been measured. A claim like "60% less evidence collection" is an ambition we will measure with a client — it is not a result, and presenting it as one would be the fastest way to lose a compliance founder's trust.

What ships, and what is an engagement

LayerStatus
Appliance, air-gap mode, hash-chained ledger, receipt rendered from itShipping
Read-only connectors, crosswalk, evidence-acceptance policy, control testing, driftWorking reference implementation, synthetic fixture
SOC 2 / ISO 27001 / NIST SP 800-171 crosswalkA declared mapping, not a certification and not a statement of applicability
Connecting a named client system (cloud, IdP, scanner, ticketing)Pilot scope, no client system has ever been contacted
Trained model for control judgementDoes not exist — and control judgement is not a model's job
Measured reduction in audit-preparation effortNot measured
Any certification, attestation, audit opinion or accreditationNone claimed and none issued
Deployment on a client siteEngagement

Where it fits

Regulated and residency-bound buyers

Health, financial services and public sector clients whose evidence cannot sit in a shared tenancy. The appliance sits inside the boundary; the collection is read-only; the assertion is the only thing that leaves.

The defence supply chain

Suppliers preparing for NIST SP 800-171 and a CMMC assessment need evidence over a period, tied to a defined boundary, with an audit trail. The engine reports coverage and gaps against the same control set — and is not an assessment, an accreditation, or a substitute for a C3PAO.

Audit-testing protection

ISO/IEC 27001 A.8.34 asks that systems and evidence be protected during audit testing. An on-premises engine that never exports raw evidence to a third party is a structural answer, not a policy paragraph.

What we are not claiming

Tell us where the evidence lives.

If a buyer's questionnaire, a residency rule or a defence clause is the reason a cloud tool is off the table, the architecture question comes before the framework question. We are happy to start there.