Assurance Center
Delivered in phases, Assurance Center separates what was requested, what the tool accepted and what is actually in place, so you can see where protection is confirmed and where follow-up is needed.
Know what is really in place.Create your account and start your guided onboarding.
The problem
A tool can accept a request and still not produce the intended result. Reports built on “accepted” give a false sense of safety.
Nobody checks whether the change actually took effect.
Assurance Center shows which protection is verified and which needs follow-up. Independent verification is being delivered in phases.
Evidence checkpoint
Inspect each checkpoint without turning a provider response into proof of the resulting state.
A required licence is not assigned across the whole target scope.
Expected answerLicensing, permissions and capability allow the control to take effect where supported.
Illustrative comparison. No customer data.
What is real today
Continuous assurance is being built in stages, and the honest version of that is more useful to you than a roadmap dressed as a product. Two parts of it run today, in modules you can open right now.
Control Fabric defines and applies selected baseline configurations, and shows where the observed state has moved away from them.
Control FabricReporting assembled from the operational security state rather than from a questionnaire filled in once a quarter.
Board evidenceReading back configured, applied, healthy and effective for the responses UnifiedONE coordinates, control by control, where the environment can be asked.
One view of expected state across every tenant an MSP manages, and an automatic second reading after a correction.
It reads. It does not act.The Assurance Center reports a gap. Correcting it runs through the module that owns the control, under that module's own approval gates and your own authority.
Your state stays yours.Verification happens against the environment that holds the state. A defensive lesson can travel between eligible participating environments. Your configuration, your records and your evidence do not.
A missing capability is shown as a gap.Where a required permission, capability or licence is not there, the platform reports the gap. It never reports protection that never happened.
Not everything can be read back.Verification depends on what an environment can be asked. A control that cannot be confirmed is reported as not verifiable, and never as verified.
Built for your team
Answer insurers and customers with evidence of what is in place.
Show each customer what was done and what is confirmed.
Give auditors and the board an honest status, gaps included.
Close incidents knowing whether the response actually worked.
Questions people ask
It is the practice of checking that an intended security control is still actually in place, instead of trusting the message that said it was applied. UnifiedONE calls the engine that does this CPA. It compares the expected state with the state it can observe, reports configured, applied, healthy and effective per control, and repeats the reading so that drift becomes visible.
In parts. Baseline configuration and drift run today through Control Fabric, and evidence assembled from the operational security state runs today through board reporting. Protection-state verification for coordinated responses is in delivery, and portfolio assurance across every tenant an MSP manages is planned. The page names each phase rather than blurring them together.
No. A successful response is a correct statement about the request that was accepted. It simply answers a smaller question than the one a security team has. Verification is the step after submission, not an accusation about the step before it.
It is when a security setting that was correct at deployment is different later. An administrator adds an exception for a migration, a licence is reassigned, a policy scope is edited, a new setting appears with a default nobody chose. None of it looks like an attack, so none of it raises an alert, and the dashboard stays green.
No, and the page will not pretend otherwise. Verification depends on what an environment can be asked, which capability is present and which licence is assigned. Coverage differs per control and per environment. A control that cannot be confirmed is reported as not verifiable, never as verified.
It reads. When a gap is found, correction runs through the module that owns the control: Control Fabric for baseline configuration, Front Gate Protection for preventive controls, SOC Commander for response. Each of those keeps its own approval gates, and your authority is binding in all of them.
No. NIS2 compliance depends on organisational, legal, governance and sector-specific requirements that no platform decides. What continuous assurance can do is help an organisation keep operational visibility and evidence about the security controls it relies on, so the move is from periodic assessment towards continuous evidence.
The more autonomous an action becomes, the more the outcome needs checking. Every automated action creates a second question: did it produce the intended defensive state? That is why verification is designed into the architecture rather than added later. UnifiedONE does not claim to verify actions taken by external AI agents.
Start here
See how UnifiedONE reads the resulting state back, surfaces drift and licence gaps instead of hiding them, and turns security posture from a snapshot into a continuous process.
Create your account and start your guided onboarding.
