ACSETalk to us
  1. Home
  2. Frameworks
  3. CCCS Medium

CCCS Medium

The CCCS Medium profile, checked in your own cloud.

Canadian public sector and regulated organizations often work to the Canadian Centre for Cyber Security’s Medium cloud profile, built on ITSG-33. ACSE checks the cloud configuration behind the profile’s technical controls and keeps the evidence in a store you own.

Talk to usSee how it works
Audit packages from sealed casesSealed cases stack into an audit package organized per framework control.AUDIT PACKAGESEALED CASESpci dss 4.0.1 · q3 · per control
01

Controls in the profile’s own terms

Results are reported by ITSG-33 control identifier, so they line up with your security assessment and authorization work.

02

Evidence you keep

Findings, decisions and verification records stay in your own cloud, signed and retention-locked.

03

Drift caught early

Each scan re-evaluates the tracked controls, so a change that weakens one shows up the same day.

Coverage

Tracked controls with a check behind them

ACSE tracks 45 ITSG-33 technical controls, by their ITSG-33 identifiers, not the whole profile. Controls without a check are listed as manual, beside the score, so nothing quietly drops out of view.

AWS
24 of 45 tracked controls
Google Cloud
15 of 45 tracked controls
Azure
12 of 45 tracked controls

Where data lives

Detail stays in your region

The ACSE runtime runs in your environment and writes evidence to a retention-locked store there. Detailed findings never leave it.

ACSE’s hosted service receives only shapes and counts, so you can choose where your evidence lives without giving up the shared view.

Your data stays in its regionFour regions, with one chosen as home. Evidence and settings stay in that region.CANADAEUROPEUNITED STATESASIA PACIFICyour home regionevidence and settings stay here

Governed change

From finding to sealed record

  1. CheckA tracked control’s check fails on a scan, and the finding names the control it affects.
  2. ProposeACSE proposes the fix as code in your repository, validated before review.
  3. ApproveA security approver who did not author the change decides with MFA.
  4. Verify and sealACSE re-reads the resource after the change applies, then seals the case in your evidence chain.
Nobody approves their own changeTwo people, a risk owner and a security approver, each confirm one change with step-up MFA. Neither of them wrote it.RISK OWNERSECURITY APPROVER✓ step-up mfa✓ step-up mfaONE CHANGEtwo people · neither of them the author

Questions

What people ask us

Does ACSE give us an authorization for CCCS Medium?

No. ACSE checks the cloud configuration behind the technical controls it tracks and keeps evidence of how findings were fixed. Assessment and authorization stay with your organization and its assessors.

Why ITSG-33 identifiers?

The CCCS Medium profile is expressed in ITSG-33 controls, which follow NIST SP 800-53 Rev. 4 numbering. ACSE uses the same identifiers so results match your documentation.

Is CCCS Medium the same as FedRAMP Moderate in ACSE?

No. They draw on related controls, but ACSE maps and reports each one separately, under its own name and version.

Keep reading

Related

Solutions

Public sector

ACSE maps your cloud to CCCS Medium, NIST 800-53 Rev 5 and FedRAMP Moderate, fixes through your own code and keeps sovereign evidence in your account.

ReadTrust

Data boundary

ACSE runs in your account and sends only shapes and counts. Names, ids and credentials stay with you, and a deny-by-default registry governs what leaves.

ReadFrameworks

NIST SP 800-53

ACSE maps cloud checks to the NIST SP 800-53 Rev. 5 technical controls it tracks across ten families, and shows each control as evaluated or manual.

Read

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to usExplore the platform