Assurance
One control plane. Multiple assurance regimes.
Dominion OS™ structures security, authority, evidence, cryptography, deployment boundaries and operational state inside one governed environment.
Dominion OS for Business and Dominion OS for Politics have distinct deployment boundaries. The same control system can then be inspected against the commercial, Canadian, British Columbia, U.S., defence and national-security requirements that apply to the actual mission.
Dominion Assurance Protocol
Build the control once. Map it where the mission requires.
Assurance starts with the operating system, not the badge. Dominion maintains a canonical control model and connects implementation evidence to external requirements.
Mission
Define users, data, jurisdictions, intended use, risk, deployment and required authority.
Guardrails
Apply identity, least privilege, cryptography, review gates, data boundaries and release discipline.
Proof
Preserve tests, configurations, artifacts, receipts, release records and accountable ownership.
Test
Verify the control inside the actual product and deployment boundary.
Translate
Cross-walk the evidence into the standards, procurement requirements and legal regimes that apply.
Declare
Record the actual assurance state without promoting a stronger claim than the evidence supports.
Claim Discipline
Five states. Five different meanings.
“Compliant” is too blunt to carry serious assurance information. Dominion separates implementation, assessment, mapping, readiness and externally conferred status.
The technical or organizational control exists.
The control has current test or review evidence.
The control has been cross-walked to an external requirement.
The architecture supports the requirement subject to the real deployment.
Certification or authorization is stated only when actually conferred.
Standards & Assurance Universe
Commercial to national security.
Applicability follows the mission, information class, contract, jurisdiction and deployment—not a generic checklist.
Enterprise
Commercial Assurance
- SOC 2 · Trust Services Criteria
- ISO/IEC 27001
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- ISO/IEC 42001
- ISO 22301
- NIST Cybersecurity Framework
- CIS Controls
- OWASP application and API guidance
Canada
Government & Protected Information
- ITSG-33 Security Control Catalogue
- Protected B / Medium Integrity / Medium Availability
- Secret / Medium Integrity / Medium Availability
- ITSP.40.111 cryptography
- ITSP.40.063 authentication and authorization
- Government of Canada cloud controls
- Contract Security Program where applicable
- Controlled Goods where applicable
British Columbia
Provincial Security & Privacy
- B.C. Government Information Security Policy
- Core Policy and Procedures Manual controls
- Applicable IM/IT security requirements
- FIPPA where applicable
- PIPA where applicable
- Data residency and contractual controls
United States
Federal & Defense
- NIST SP 800-53 Rev. 5
- NIST SP 800-171 Rev. 3
- NIST SP 800-171A Rev. 3
- NIST SP 800-172
- CMMC where contractually applicable
- DFARS cybersecurity clauses
- FedRAMP authorization pathway
- Federal Zero Trust requirements
Cryptography
Classical + Post-Quantum
- FIPS 140-3
- FIPS 197 · AES
- FIPS 186-5
- NIST SP 800-56
- NIST SP 800-57
- FIPS 203 · ML-KEM
- FIPS 204 · ML-DSA
- FIPS 205 · SLH-DSA
- Cryptographic agility and inventory
National Security
Defence & Intelligence
- CNSSI 1253 mappings
- NSA CNSA 2.0
- Commercial Solutions for Classified patterns
- Applicable CSfC Capability Packages
- NIAP / Common Criteria where relevant
- DISA STIG / SRG where relevant
- Private, isolated and sovereign deployment patterns
Dominion Assurance Matrix
The standards collapse into control domains.
Exact implementation state belongs to the relevant product release and deployment boundary.
| Control Domain | Dominion Evidence | Canada / B.C. | United States | Defence / Intelligence | Public Posture |
|---|---|---|---|---|---|
| Identity & Authority | Authentication, roles, approval gates, accountable actions | ITSG-33 · ITSP.40.063 · B.C. ISP | 800-53 · 800-171 · Zero Trust | CNSSI 1253 | Mapped Deployment-specific |
| Cryptography & Keys | Encryption boundary, protocols, lifecycle, inventory | ITSP.40.111 | FIPS 140-3 · 197 · 203 · 204 · 205 | CNSA 2.0 · CSfC | Mapped Validation-dependent |
| Audit & Evidence | Receipts, logs, state, releases, review history | ITSG-33 audit families | 800-53 AU · SOC 2 | NSS audit controls | Core design |
| Software Supply Chain | Source control, dependency governance, provenance, releases | ITSG-33 · B.C. controls | 800-53 SR · CMMC | NSS supply-chain controls | Evidence-led |
| Resilience & Recovery | Health, staged change, backup, recovery, rollback | ITSG-33 · continuity controls | 800-53 CP · SOC 2 Availability | Mission continuity | Deployment-specific |
| Dual-Use Governance | Mission, end user, jurisdiction, licensing, authority | Contract · Controlled Goods where applicable | Contract · export / procurement controls | Mission authorization | Licensed Scoped |
Evidence Architecture
The evidence is part of the operating system.
Assurance gets stronger when operating state can be inspected rather than reconstructed after the fact.
Control Registry
Control identity, purpose, ownership, scope and mappings.
Evidence Registry
Tests, configurations, receipts, artifacts and review evidence.
Release Registry
Version, artifact, promotion state and release evidence.
Provider Matrix
Provider-specific capabilities, dependencies and unresolved gates.
Assessment State
Implemented, assessed, mapped, ready or externally conferred.
Open Gaps
Unresolved requirements remain visible until evidence closes them.
Dual-Use Assurance
Capability does not outrun authority.
Serious capability changes the standard of care. Intended use, jurisdiction, end user, information class, deployment architecture and operating authority must remain explicit.
Establish legitimate use
Define the actual mission, operators, decisions and information boundary.
Know where access occurs
Identify infrastructure, administrators, remote access and cross-border movement.
Classify technology and data
Review controlled technology, cryptography, technical data and applicable restrictions.
Control the environment
Apply identity, keys, segmentation, least privilege and human approval.
Write the permitted scope
Approved terms define customer, users, modules, mission and environment.
Material change triggers review
Changed missions, integrations, jurisdictions or users can require re-approval.
Public Claim Boundary
Evidence before adjectives.
This page means
- Dominion is designed around governed controls and evidence.
- Controls can be mapped against applicable assurance regimes.
- Exact requirements follow the actual deployment.
- Evidence supports procurement, security and assurance review.
- Stronger states require stronger proof.
This page does not mean
- Framework mapping equals certification.
- Architectural compatibility equals government authorization.
- A FIPS algorithm automatically creates a validated module.
- CSfC-aligned architecture means CSfC registration.
- A deployment is FedRAMP authorized without authorization.
- SOC 2 is claimed without the applicable examination.
Reference Authorities
Primary sources over compliance folklore.
Next Step
Start with the mission. Then prove the system.
Bring the procurement requirement, protected-data problem, control set, security regime or deployment constraint. Fractal5 will scope the smallest credible assurance path around the system that actually needs to operate.
Standards, legislation, policies, contractual requirements and assurance programs change. Inclusion on this page identifies an applicable or potentially applicable control-mapping regime. It does not by itself state that Fractal5 Solutions Inc., Dominion OS™, the Fractal5 SaaS Suite or a customer deployment holds a certification, authorization, validation, clearance, accreditation or registration. Exact status is established from current evidence for the applicable organization, product, release and deployment boundary.