Cloud Security Assessment and Authorization in the Government of Canada

Most cloud authorizations in the Government of Canada stall in the same place. Not at the technology, and not at the paperwork at the end — but somewhere in the middle, where nobody can say cleanly which controls belong to the cloud service provider, which belong to the department, and what evidence is supposed to close the gap between them.

The Canadian Centre for Cyber Security publishes a full answer to that question. It is spread across four documents, and the one that ties them together is ITSP.50.105, Guidance on cloud security assessment and authorization.¹ This article walks the whole process end to end: what happens at each step, who does it, what evidence it produces, and where practitioners most often get stuck.

The Nine Steps Behind Every Cloud Authorization#

The Cyber Centre's cloud security risk management approach, set out in ITSM.50.062, defines nine steps.² Every other document in the suite is an expansion of part of it. Knowing which step you are on tells you which guidance to open — and which conversation you should be having.

Scroll the diagram sideways to see every profile →

The approach sits inside the information-system-level activities of the Cyber Centre's risk management lifecycle — ITSG-33 Annex 2, still current — and adapts them for an environment where somebody else operates most of the stack.³

Step 1 — Security Categorization Comes First#

Nothing about a cloud assessment can be scoped until the workload has been categorized. ITSP.50.103 sets out four activities.⁵

1. Develop an Injury Assessment TableThe scale you will measure against
2. Inventory Business Processes and Information AssetsWhat is actually in scope
3. Assess InjuryExpected injury from a compromise of each objective
4. Analyze Business DomainsGroup processes that share a security category

Injury is assessed against the three security objectives, at Low, Medium or High:

Step 2 — Selecting the Cloud Control Profile#

Cloud control profiles are derived from the baseline profiles in Annex 4 of ITSG-33 and adapted for cloud.

Security control profiles have been developed for cloud-based services based upon the baseline profiles in Annex 4 of ITSG-33. The cloud security control profiles identify the recommended security controls that your CSP and your organization should implement for the assessed security category of each respective business domain. The selected cloud control profile also serves as the basis for assessment of the security controls.

ITSP.50.105 § 2.1

Three profiles are used in the CCCS cloud assessment workbooks:

ITSP.50.103 publishes two of these directly — Annex A Cloud Control Profile – Low and Annex B Cloud Control Profile – Medium. For high-category business activities it directs organizations to contact the Cyber Centre for the recommended profile.⁵

That quotation dates from 2020. The lifecycle it points at is unchanged, but the catalogue underneath it is now ITSP.10.033, and its organizational profile counterpart is published as ITSP.10.033-01.⁴

A profile is a starting point, not a finished control set. ITSP.50.105 is explicit that tailoring is expected: profiles must be adjusted for unique threats, technical limitations, business requirements, legislation, policies and regulations, and your organization is responsible for identifying every compliance obligation that applies.¹

Step 3 — Deployment and Service Models#

Two independent choices, both of which change the assessment.

Deployment models — public, private, hybrid and community. Service models — Infrastructure as a Service, Platform as a Service, and Software as a Service.⁵

Profile, assessment type and service model together determine which assessment you are actually running:

Scroll the diagram sideways to see every profile →

The practical consequence: at Cloud Low there is no IaaS or PaaS path. A department that categorizes a workload as Cloud Low and then plans an IaaS deployment has a contradiction to resolve before it writes a single assessment artifact.

Who Assesses What#

This is the hinge the whole process turns on, and it is worth stating plainly:

Your organization does not have direct control or the necessary visibility to directly assess controls under the responsibility of the CSP. For that reason, your organization should review formal certifications or attestations from independent third-parties to verify that the CSP has implemented their controls and that they are functioning effectively. Your organization should directly assess any controls within the scope of its responsibilities.

ITSP.50.105 § 2.1

Two assessment types, one profile:

Where the boundary falls depends on the service model. The further up the stack the service sits, the more of it you are taking on trust — and the more your assurance rests on somebody else's audit report.

Scroll the diagram sideways to see every profile →

Each control in a profile is allocated to a responsibility type:

ITSP.50.105 also sets out what each party owes the other. Cloud consumers must understand which controls are theirs, run the required threat and risk assessments and privacy impact assessments, oblige the CSP by contract to evidence compliance through independent third-party attestation, and manage the residual risk. CSPs must document the security controls and features their services provide, meet contractual and service-level commitments, evidence compliance periodically through the life of the contract, explain how to deploy securely on their platform, and report incidents and changes in security posture.¹

Step 4 — Assessing the CSP#

The assessment committee#

ITSP.50.105 recommends the CSP assessment be overseen by a committee rather than an individual — "a security assessor, a cloud security architect, an IT practitioner, and a compliance officer".¹ Each brings a lens the others do not have, and the composition is a reasonable check on whether you have the right people in the room before you begin.

Three things must be settled before the assessment starts: a non-disclosure agreement with the CSP, the target security categorization, and the selected service model and control profile.

The process#

1. Determine required reportsWhich current third-party reports, attestations and certifications apply
2. Confirm scope and periodWhat each attestation actually covers, and when
3. Review detailed evidenceAttestations, CSP interviews, FedRAMP SSP, RFP responses, self-assessments, public information
4. Prepare the CSP assessment reportScope, evidence, gaps, consumer dependencies, recommendations
5. Continuously monitorRefresh the evidence on a contractual cadence

The detailed evidence review is looking for two things: that the control and enhancement requirements defined by the selected profile have been met, and that the documentation gives enough assurance that the CSP's services are appropriately designed, operated and maintained.

Five areas deserve particular attention — the security of the underlying cloud fabric, the isolation of that fabric from the CSP's own network and systems, the isolation of tenants from one another, the security of the management plane, and the security of interfaces and APIs.¹

The report, and what to do with a gap#

A CSP assessment report should describe the CSP assessed, the committee and their roles, the security category and service and deployment models, the control requirements, the assessment scope by location and service, the documents reviewed and the period they cover, the control gaps identified, anything your organization must now provide in policy, practice, service or configuration, recommended contract terms, and a summary of residual risks and recommendations.

When a gap appears, there are three honest responses:

1. Fill the gap with your own controls.
2. Accept the residual risk.
3. Select a different CSP.

Stack assessments#

Cloud services are built on other cloud services, and assessments stack the same way.

The cloud security risk management approach allows for the stacking of assessments like building blocks. In this model, the assessment for each cloud system must only cover the implementation of that specific system. For example, a SaaS service provider would not specify in its own documentation, implementation details, or evidence related to the infrastructure service that it leverages.

ITSP.50.105 § 3.3.3

A SaaS provider running on a major IaaS platform is not expected to re-evidence that platform. It inherits it. That keeps assessments bounded by system boundaries and stops the same infrastructure being assessed a dozen times over.

Reading Third-Party Attestations#

Most of a CSP assessment is document review, and most of the value is in reading those documents properly rather than filing them.

System and Organization Controls#

A Type 1 report attests to the design of controls at a point in time. A Type 2 report covers a minimum six-month period and includes operating effectiveness. ITSP.50.105 recommends SOC 2 Type 2 for the additional assurance it provides, and advises against relying on SOC 3.¹

Four things to check in every report:

• Scope — does it cover the hosting locations, dates, cloud services and trust services principles you actually rely on?
• The auditor's opinion — an unmodified opinion means the auditor fully supports management's assertion. A qualified opinion signals a scope limitation or significant control exceptions. A disclaimer means the auditor could not express an opinion. A negative opinion is serious enough that ITSP.50.105 advises discussing it with the CSP before using the service at all.
• Complementary user entity controls — the controls the report assumes you are operating. Determine which apply and verify your own controls address them.
• Subservice organizations — if the CSP depends on one, confirm the relevant controls are inside the report's scope rather than carved out of it.

ISO 27001, 27017 and 27018#

ISO/IEC 27001 certifies an information security management system; ISO/IEC 27017 adds cloud-specific controls and ISO/IEC 27018 covers protection of personal information in public clouds. Check the certificate scope against the hosting locations, timeframes and services you use, and read the non-conformity status: recommended means none were found, recommended upon action plan development generally follows minor non-conformities, and not recommended follows a major non-conformity or an accumulation of minor ones.¹

CSA STAR#

The Cloud Security Alliance STAR program has three levels: Level 1 self-assessment against the Consensus Assessments Initiative Questionnaire, Level 2 independent third-party assessment, and Level 3 continuous auditing, which the CSA was still developing when ITSP.50.105 was published. Level 2 attestations follow SOC 2 and report against the 16 security domains of the Cloud Controls Matrix; Level 2 certifications score maturity across five management principles and result in a bronze, silver or gold designation.

FedRAMP#

Steps 5 and 6 — Your Own Controls#

Step 5 is implementation; step 6 assesses what you built. The assessment determines whether the selected controls are met per the profile's requirements and whether they are appropriately designed, implemented, operated and maintained.

Inherit before you assess#

Reusing pre-approved security design patterns, compliance templates, disk images, scripts and control-implementation documentation means inheriting controls that have already been assessed — and concentrating the assessment effort on what is genuinely specific to this service. In a department running more than one cloud workload, this is the difference between an assessment program that scales and one that repeats itself.

Cloud-specific considerations#

Annex A of ITSP.50.105 maps the defence-in-depth guidance of ITSP.50.104 onto control areas.⁶ Condensed, the areas an assessor should expect to see addressed:

Automation, DevSecOps and a warning about scanning#

ITSP.50.105 is unusually blunt about manual assessment: it requires a lot of effort, is time consuming, and "does not align well with the agility of the cloud environment".¹ The recommended direction is automated enforcement and reporting on baseline configuration, with security testing built into a DevSecOps pipeline — static analysis in the IDE and source control, dynamic testing and baseline scanning through build and test, runtime protection in production.

Two operational cautions:

Step 7 — Authorization#

Authorization is the ongoing process of obtaining and maintaining official management decisions by a senior organizational official for the operation of an information system. Through authorization, the authorizer clearly accepts the risk of relying on the information system to support a set of business activities based on the implementation of an agreed-upon set of security controls and the results of continuous security assessments.

ITSP.50.105 § 4.3.2

Three sub-steps.

Define and document required mitigation activities. Gaps that remain go into a Plan of Action and Milestones, with owners and timelines for correction or mitigation.

Assemble and submit the authorization package. Every document produced or referenced during the assessment, the evidence for controls inherited from other services, the authorization letter, and the PoAM. Crucially, the package covers the whole thing:

When granting an authorization, a consumer organization must authorize the use of the entire cloud-based service, which consists of both the CSP cloud services and the consumer organization service hosted on these cloud services.

ITSP.50.105 § 4.3.2

Grant the authorization. The authorizing official makes a risk-based decision. Whatever they decide, the documentation must record the decision itself, any conditions on operating the service, required mitigation efforts and their target dates, and management's intent in operating the service.

Where a mature DevSecOps pipeline exists, ITSP.50.105 contemplates automating the criteria that gate a release into production: high and critical scan issues resolved, high and critical bug fixes applied, third-party library vulnerabilities and licence issues resolved, deviations from coding standards and from the security baseline addressed, automated control verifications successful, and no substantive change to the service.

Steps 8 and 9 — Monitoring and Keeping the Authorization#

On the CSP side#

Third-party reports cover a defined period, and that period ends. Contracts should require continuing coverage — typically annual — and each new report needs analysing for gaps and concerns rather than filing. CSPs generally make periodic assessments available, and their scope usually includes services released since the last period.

On your side#

The continuous monitoring approach defines how the security controls of cloud-based services are monitored over time, and how monitoring data is used to determine if these services are still operating within their authorization parameters.

ITSP.50.105 § 4.3.3

In practice that means periodic assessment of controls — preferably automated — periodic review of security events and incident reports, and periodic review of operational personnel security activities. Both the service running on the cloud platform and the infrastructure you use to reach and consume it are in scope.

When something drifts#

When a service moves outside its authorization parameters, ITSP.50.105 sets out three responses: implement temporary measures to protect the supported business activities, update controls to correct the deficiency, or accept the new level of residual risk. If the residual risk remains unacceptable after remediation, the authorizer may revoke the authority to operate pending further action.

That last sentence is the one worth reading twice. An authority to operate is a live decision that can be withdrawn — not a certificate with an expiry date.

The Traditional Path vs the Cloud Path#

A persistent misconception is that a cloud assessment demands the same baseline tailoring exercise as a traditional ITSG-33 assessment. It does not, because the cloud profiles are already cloud-adapted baselines.

The work does not disappear. It moves — from deciding which controls apply to establishing who owns each one and whether it has been implemented effectively.

Frequently Asked Questions#

Which CCCS cloud profile applies to a Protected B workload?#

Both Cloud Medium and Cloud High are Protected B for confidentiality. Cloud Medium pairs Protected B with Medium integrity and Medium availability; Cloud High pairs the same confidentiality level with High integrity and High availability. The integrity and availability results of your security categorization decide between them.

What is the difference between a CSP assessment and a client assessment?#

A CSP assessment evaluates the controls implemented by the cloud service provider — infrastructure, platform, service operations and security controls. A client assessment evaluates the controls implemented by the consuming department — business processes, access management, tenant configuration and data governance. Both draw on the same cloud control profile, and an authorization needs both.

Do I have to assess the CSP myself?#

No, and generally you cannot. ITSP.50.105 states that your organization has neither direct control nor the visibility needed to assess controls under CSP responsibility, and directs you to rely on formal certifications and attestations from independent third parties instead. What you assess directly are the controls within your own responsibility.

Which third-party report should I ask a CSP for?#

A SOC 2 Type 2 report, because it covers operating effectiveness over a period of at least six months rather than design at a point in time. ISO 27001 with 27017 and 27018, and CSA STAR Level 2, add useful coverage. SOC 3 is explicitly not recommended — it lacks the detail needed to assess a provider properly.

Can the Cloud Low profile be used for an IaaS assessment?#

No. In the CCCS cloud assessment workbooks, Cloud Low supports SaaS only, for both CSP and client assessments. IaaS and PaaS assessment paths begin at Cloud Medium.

Does a cloud assessment replace ITSG-33?#

No. It sits inside the same information-system-level risk management activities and keeps security categorization intact. What it replaces is the extensive baseline tailoring exercise — the cloud profiles are predefined cloud control baselines, so effort moves to assigning responsibility across CSP, client, shared and inherited controls and confirming effective implementation.

Is ITSG-33 still current?#

Partly. On 31 March 2026, ITSP.10.033 superseded ITSG-33 Annex 3A, the security control catalogue, so control references should now point at ITSP.10.033 — an adapted version of NIST SP 800-53 Rev. 5. The rest of ITSG-33 has not been withdrawn: the Cyber Centre still publishes Annexes 1, 2, 4A and 5 and states the information remains valid. Cloud publications written before 2026 cite ITSG-33 throughout; read the process references as current and the catalogue references as pointing at ITSP.10.033.

How long does an authorization last?#

It is not a fixed term. Authorization is an ongoing process sustained by continuous monitoring, and it holds only while the service operates within its authorization parameters. Drift outside them triggers remediation, risk re-acceptance, or revocation of the authority to operate.

References#

1. ITSP.50.105 — Guidance on cloud security assessment and authorization ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-cloud-security-assessment-and-authorization-itsp50105
2. ITSM.50.062 — Cloud security risk management ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cloud-security-risk-management-itsm50062
3. ITSG-33 — IT security risk management: A lifecycle approach ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/it-security-risk-management-lifecycle-approach-itsg-33
4. ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
5. ITSP.50.103 — Guidance on the security categorization of cloud-based services ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-security-categorization-cloud-based-services-itsp50103
6. ITSP.50.104 — Guidance on defence in depth for cloud-based services ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/itsp50104-guidance-defence-depth-cloud-based-services
7. ITSM.50.100 — Cloud service provider information technology security assessment process ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cloud-service-provider-information-technology-security-assessment-process-itsm50100
8. Government of Canada Security Control Profile for Cloud-Based GC Services ↩Government of Canada · https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/government-canada-security-control-profile-cloud-based-it-services.html
9. Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice ↩Treasury Board of Canada Secretariat · https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/direction-secure-use-commercial-cloud-services-spin.html