Skip to main content
Reynar IT
Sovereignty as a Service

Sovereignty
You Can Prove

One product, the licensed Sovereignty Architecture. One service, supporting it in your existing environment. Scope, controls and evidence are defined by your workload, not by a package.

Book a Briefing Why Residency Is Not Enough
Start Here

One Workload. One Assessment.

Every engagement begins the same way: a single workload, assessed against the control and evidence it is required to have. No platform decision, no procurement, no minimum scope.

Book an Assessment Briefing
You bring
  • One workload and where it runs today
  • Its information category and who is accountable for it
  • The obligation, assessor or audit it must satisfy
We examine
  • Who can decide, administer, verify and recover today
  • Where keys and evidence are held, and by whom
  • Every remote administrative path, foreign or domestic
You receive
  • A written finding: control gaps and evidence gaps, each traced to its requirement
  • The proposed tier and boundary for this workload
  • A decision you can take to your own authority

The Product: A Licensed Architecture

The Sovereignty Architecture is a maintained control model. It connects authority, access, keys, updates, network boundaries, evidence and recovery so each sovereignty claim can be traced to a requirement, a mechanism and a test. It is deployed as a Zone and Domain inside your environment.

Authority and Custody

Definitions of who may decide, administer, verify and recover, and where keys and evidence are held.

Control Requirements and Traceability

Each control linked to its source requirement, mechanism, owner, test and expected evidence.

Runbooks

Procedures for operation, change, verification, firmware release and break-glass, with separation of duties built in.

Network Enforcement Patterns

Zone and domain boundaries, interconnect controls and a rule catalogue template for your environment.

Validation Methods

Acceptance scenarios and inspection procedures that show a control works, not just that it was designed.

Evidence Model

Signed, tamper-evident records retained inside the zone and made available to your own assessor.

The Service: Support in Your Environment

Support covers what your deployment needs, from first assessment to steady-state operation. Delivery execution is provided by a Canadian delivery integrator with execution capacity only: it cannot verify its own work, sign firmware releases, authorize break-glass access or define the architecture.

Assessment

Your workload, information category, existing controls and the gap between them and the required outcome.

Design

The control boundary, supported components and versions, required changes and residual dependencies.

Integration Support

Deployment into your environment, with execution by a Canadian delivery integrator under defined limits.

Validation

Acceptance testing with observed results, open exceptions and your decisions recorded.

Operation

Running the control model under an agreed allocation of authority, with independent verification roles kept separate.

Training

Preparing your team to operate the model themselves from the released materials.

What the Architecture Controls

Sovereignty holds only when every layer holds. The architecture defines each control, how it is enforced and the evidence that shows it is working. Three roles are kept separate by design: you hold authority, a delivery integrator can only execute, and a verifier can only inspect.

How the Sovereignty Architecture separates authority, execution and verification A sovereign zone sits inside the customer's own environment and holds the hardware security modules, the evidence store and the workload. The customer holds authority and the key quorum. A Canadian delivery integrator can only execute within defined limits. An independent verifier checks results and cannot execute. There is no foreign remote administrative path into the zone. YOUR ENVIRONMENT SOVEREIGN ZONE Boundary enforced by the architecture, not by contract Key Custody HSMs you physically hold Quorum belongs to you Evidence Store Signed, tamper-evident Retained inside the zone Your Workload Canadian-controlled identity · Segmented network Controlled updates · Dual-person privileged actions Recovery Your existing DR arrangement, zone controls extended to it AUTHORITY You Decide · Hold the keys · Recover Approve break-glass ARCHITECTURE Reynar IT Licensed control model, runbooks, validation methods, support EXECUTION ONLY Delivery Integrator Canadian firm, builds within limits Cannot verify, sign or authorize VERIFICATION Independent Verifier Inspects evidence and tests Cannot execute changes Foreign remote administration No path at any layer Three roles, kept separate. Each claim traces to a requirement, a mechanism, a test and a record.
Diagram of the Sovereignty Architecture: the customer holds authority and keys, Reynar IT provides the licensed control model, a Canadian delivery integrator executes within limits, an independent verifier inspects, and no foreign remote administrative path exists.

Authority and Access

Defined authority for every role, Canadian-controlled identity, and dual-person privileged actions with recorded sessions.

Key Custody

Hardware security modules held in your physical custody, with a key quorum that belongs to you.

Network Boundaries

Segmented zones with enforced interconnect controls and no foreign remote administrative path.

Controlled Updates

Vendor updates validated in a separate environment before they reach production, where the scope requires it.

Signed Evidence

Tamper-evident records retained inside the zone, ready for your assessor, auditor or privacy office.

Recovery

Zone controls extended to your existing disaster recovery arrangement, so continuity does not reopen the boundary.

Where It Runs

You deploy where you already are. Reynar IT brings the control model, not a facility, floor space, power or hardware. There is no minimum deployment.

Your environment needs a few things for the controls to hold: physical custody of the hardware security modules, Canadian-resident operations staff, no foreign remote administrative path, controlled physical access to the zone, and an evidence store inside it.

Disaster recovery uses your existing arrangement, with the zone controls extended to it.

What It Is Not

  • Not a cloud region, a hosting contract or a capacity rental.
  • Not a residency promise. Residency is necessary but not sufficient.
  • Not a certification or an authorization. Your responsible authorities evaluate the system.
  • Not a fixed bill of materials or a minimum purchase.

Proposed Tiers

Three tiers are proposed, named by the level of control they establish. Their exact scope is set with each customer. A tier is designed to support a profile; it does not by itself establish compliance or authorization, which remain with your responsible authorities. Protected C and Secret are different categories.

Proposed Tier

Custody

Workloads that need demonstrable Canadian control

Canadian custody of keys, administration and evidence, with the authority model and signed records in place.

Proposed Tier

Dedicated Zone

Designed to support a Protected B profile (ITSP.10.033-01)

Restricted, role-based access in a segmented zone, with controls selected from the Canadian Centre for Cyber Security catalogue and validated in your environment.

Proposed Tier

Named Access

Designed to support Protected C controls

Named-individual access, dual-person privileged actions, controlled updates and no foreign path at any layer.

Standards We Work From

Controls are selected from the Canadian Centre for Cyber Security's current guidance, so security teams can assess them the way they assess everything else. A mapping is claimed only where it exists for your scope, with its rationale, owner, mechanism, evidence and test.

ITSP.10.033

Security and privacy control catalogue (supersedes ITSG-33 Annex 3A).

ITSP.10.033-01

Suggested Medium impact profile, tailored to the workload (supersedes ITSG-33 PBMM).

ITSP.10.036

Organizational risk management and approval process (supersedes ITSG-33 Annex 1).

ITSP.50.105

Cloud assessment and authorization, where your deployment includes cloud responsibilities.

Privacy obligations such as Alberta's Protection of Privacy Act and the Personal Information Protection Act are applied where they govern your organization.

Who It Is For

Government of Alberta

Ministries, agencies and public bodies accountable under the Protection of Privacy Act for where data goes and who can reach it.

Federal Departments

Workloads that need a demonstrable control chain for authority, access, data flows and continuity.

Security-Cleared Environments

Workloads where the system boundary, personnel clearances and authorization path govern what can be deployed. Scope is set with the responsible authority.

Regulated Sectors

Legal, health and financial organizations protecting confidential information and governing their use of AI.

Start a Conversation

Ready to Discuss Your Next Move?

Start with one workload: the information it holds, who is accountable for it, and the control or evidence gap you need to close.

Book a Briefing Email Directly
No Obligation Confidential