Skip to content

CCCS Medium Cloud Control Profile

Best for: Canadian federal departments and agencies deploying cloud workloads for data categorized at Protected B, Medium Integrity, Medium Availability (PBMM). Cloud service providers seeking authorization to host GC workloads must also meet this profile. Provincial governments and Crown corporations sometimes adopt it voluntarily. If you deliver cloud services through GC procurement vehicles, this profile is expected for in-scope workloads.

Mandatory?Mandatory for Canadian federal departments adopting cloud (Protected B)
Who validates?CCCS security assessment; departmental ATO · No self-assessment
RenewalReassessment at major system changes; no fixed cycle
ScopeCloud services handling Protected B, Medium Integrity, Medium Availability data

🏛 Treasury Board of Canada Secretariat (TBS), with technical input from the Canadian Centre for Cyber Security (CCCS) within the Communications Security Establishment (CSE) · CCCS Medium Cloud Control Profile Official source →

Get Started

module "..." {
  source  = "cccsmedium.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

  • What Compliance.tf automates

    • IAM Password Policy: Runs 9 controls against the AWS IAM account password policy, covering minimum length (14 characters), complexity requirements (uppercase, lowercase, number, symbol), reuse history (24 passwords), and the 90-day expiration setting.
    • IAM Privilege Management: Checks root MFA status, flags access keys inactive for 45 or more days, and scans both managed and inline policies for wildcard service actions and blocked KMS actions.
    • Encryption in Transit: Validates SSL/TLS certificate assignment on Application Load Balancers, Network Load Balancers, and Classic Load Balancers, and confirms HTTPS-only listeners on Classic LBs.
    • Backup and Recovery: Verifies that configured AWS Backup plan rules enforce a minimum 35-day retention period.
    • Monitoring and Incident Detection: Confirms CloudWatch alarms have associated actions configured, catching orphaned alarms that would otherwise generate no notification or automated response.

  • What you handle

    • IAM Password Policy: Password policy enforcement for federated identity providers (Azure AD, Okta) outside AWS IAM is out of scope for these checks. Document policy exceptions and the approval workflows behind them.
    • IAM Privilege Management: Periodic access reviews and RBAC documentation remain manual tasks. You also need to define the organization-specific list of blocked KMS actions and rotate or remove keys on the identified timeline.
    • Encryption in Transit: TLS policy version selection (e.g., ELBSecurityPolicy-TLS13-1-2-2021-06), certificate lifecycle and renewal, and end-to-end encryption between load balancers and backend targets.
    • Backup and Recovery: Test restoration procedures, document recovery time and recovery point objectives, and confirm backup plans cover all in-scope resources including databases and file systems.
    • Monitoring and Incident Detection: Set thresholds appropriate to your workload, build incident response runbooks, and connect CloudWatch to your SIEM or GC-approved security operations tooling.

Controls by Category

Backup and Recovery (1 control)

The 35-day retention floor is the specific threshold assessors verify against configured backup rules. It supports the Medium Availability requirement by ensuring recovery points span a reasonable operational window. Watch for non-production environments that still hold Protected B data and have shorter retention configured; those create compliance gaps.

Backup plan min frequency and min retention check

Encryption in Transit (1 control)

No HTTP-only listeners are acceptable; every load balancer endpoint must enforce TLS. Classic load balancers are a persistent source of findings because teams defer migration or forget to apply updated TLS policies. Assessors check the TLS policy version specifically to confirm TLS 1.2 as the minimum.

ELB application and network load balancers should only use SSL or HTTPS listeners compliance.tf module

IAM Password Policy (9 controls)

A common finding here is organizations setting minimum password length to 8 when this profile requires 14 characters. Assessors check every parameter of the AWS account-level policy: minimum length, all four complexity flags, 24-password history, and 90-day expiration. Evidence typically includes an IAM credential report alongside a screenshot of the active policy configuration.

Ensure IAM password policy requires a minimum length of 14 or greater Ensure IAM password policy requires at least one lowercase letter Ensure IAM password policy requires at least one number Ensure IAM password policy requires at least one symbol Ensure IAM password policy requires at least one uppercase letter Ensure IAM password policy prevents password reuse Password policies for IAM users should have strong configurations with minimum length of 8 or greater IAM password policies for users should have strong configurations Ensure IAM password policy expires passwords within 90 days or less

Monitoring and Alerting (1 control)

An alarm with no configured action is useless for incident response. Assessors verify that every CloudWatch alarm routes to an SNS topic, Auto Scaling action, or Lambda trigger, per the CCCS requirement for timely notification of security events.

CloudWatch alarm should have an action configured compliance.tf module
Additional Controls (9)

AWS KMS (1)

KMS CMK rotation should be enabled compliance.tf module

AWS Secrets Manager (1)

Secrets Manager secrets should be encrypted using CMK compliance.tf module

Amazon RDS (1)

RDS DB instance multiple az should be enabled compliance.tf module

Amazon Redshift (1)

AWS Redshift clusters should have automatic snapshots enabled compliance.tf module

Amazon S3 (3)

S3 buckets should have lifecycle policies configured compliance.tf module S3 buckets should prohibit public write access compliance.tf module S3 buckets with versioning enabled should have lifecycle policies configured compliance.tf module

Amazon SNS (1)

SNS topics should be encrypted at rest compliance.tf module

Amazon VPC (1)

VPC Security groups should only allow unrestricted incoming traffic for authorized ports compliance.tf module

  • NIST 800-53 Rev 4 — 🟢 High overlap (80%)

    CCCS Medium is derived from ITSG-33 tailored controls, which are based on NIST SP 800-53 Rev. 4. Most controls map to families including AC, IA, SC, AU, and CP, with Canadian tailoring for Government of Canada implementation context.

  • NIST CSF — 🟡 Medium overlap (45%)

    NIST CSF provides a higher-level risk management structure built on the same NIST 800-53 foundations underlying CCCS Medium. CCCS Medium controls are more technically prescriptive than CSF subcategories.

  • AWS Foundational Security Best Practices — 🟡 Medium overlap (55%)

    AWS Foundational Security Best Practices covers common ground on IAM, encryption, and monitoring controls. CCCS Medium adds Government of Canada SA&A evidence requirements and control tailoring that go beyond AWS service-level checks.

Frequently Asked Questions

Does CCCS Medium apply to my organization if we are not a Canadian federal department?

It depends on your relationship with the Government of Canada. Cloud service providers hosting GC workloads or contractors processing Protected B data on behalf of a federal department will be pulled into the department's SA&A process and required to demonstrate compliance with CCCS Medium controls. Provincial governments and private-sector organizations are not required to adopt it but sometimes use it voluntarily as a baseline.

What is the difference between CCCS Medium and ITSG-33?

ITSG-33 is the broader IT Security Risk Management framework published by CSE, defining security control profiles for different categorization levels. CCCS Medium is a cloud-specific profile derived from ITSG-33 Annex 4, scoped to the Protected B / Medium Integrity / Medium Availability categorization. ITSG-33 is the parent framework; CCCS Medium is the cloud-specific child profile.

How long does the SA&A process take for a CCCS Medium cloud deployment?

No fixed government-wide timeline applies. Departmental SA&A for cloud deployments typically runs several months, depending on architecture complexity, control maturity, and assessor availability. Reusing a cloud service with existing GC assessment artifacts reduces tenant-level effort, but department-specific authorization steps are still required.

Can I satisfy CCCS Medium by running only automated checks, or is manual evidence required?

Automated checks cover the technical control implementation, but manual evidence is still required for procedural and administrative controls: security awareness training records, incident response plans, personnel security screening, physical security of on-premises components, and documented risk acceptance decisions. An SA&A assessor will expect both.

Does CCCS Medium require data residency in Canada?

The profile applies alongside GC policy and contractual requirements on approved data location. For Protected B workloads, departments generally require storage and processing in approved Canadian regions unless an approved exception is in place. SA&A documentation should confirm that data, including backups and logs, stays within approved locations.