Most cloud security assessment checklists come from security vendors, and none of the top five we read on Google.ca cite a Canadian standard. That's odd, because Canada's Cyber Centre publishes its own, and it answers the question most checklists skip: who owns each control. Its Medium cloud profile lists 353 security controls and marks, for each one, whether the provider or the customer has to deal with it. On software as a service, the Microsoft 365 or payroll-app model, 171 of those controls are still marked for the customer. All 36 backup and recovery controls are the customer's on every model.
This checklist maps each check to the control it comes from in that profile, says what evidence to keep, and covers the Canadian rules on where your data can sit. It's written for owners and IT leads at Canadian firms running Microsoft 365, AWS or Azure, and for SaaS companies whose buyers have started asking for a CCCS assessment.
Here's the short answer. A cloud security assessment checks how your cloud services are set up against a published baseline, and checks the provider's half with evidence instead of trust. In Canada, the baseline worth using is the Canadian Centre for Cyber Security (CCCS) cloud profile: Low or Medium, depending on how much harm a leak or an outage would cause. The work runs in seven steps: list every account, categorise the data, pick the profile, review the provider's audit reports, test your own settings, fix and record what you find, then keep monitoring.
Keeping Quebec residents' personal information in a cloud region outside Quebec? Section 17 of Quebec's private-sector privacy act requires a privacy impact assessment and a written agreement first. Our free Quebec Law 25 readiness assessment shows where you stand.
What is a cloud security assessment?
A cloud security assessment is a structured review of three things: the settings you control in your cloud accounts, the controls your provider says it runs, and the gap between the two. It ends with findings ranked by risk and a plan to close them.
You'll see several names for the same job. A cloud security risk assessment, or cloud computing security risk assessment, puts more weight on likelihood and impact. A cloud security posture assessment is the configuration slice: settings, exposure and drift. A cloud infrastructure security assessment looks only at IaaS, meaning virtual machines, networks and storage. A cloud security maturity assessment scores your processes on a scale instead of against a control list.
They overlap a lot. What matters is the baseline you measure against, and whether the report says who owns each gap.
Is cloud security the same as cybersecurity?
No. Cloud security is part of cybersecurity, with one big difference: you share the job with a provider you can't inspect.
The Cyber Centre puts it plainly: "Cloud security assessment and monitoring is a shared responsibility" (ITSP.50.105, section 2.2). The same guidance says your organisation still "is responsible for determining and managing the residual risks." You can't walk into a provider's data centre, so you rely on its audit reports for that half. Your half, mostly identity, settings, data and recovery, is yours to test directly.
How is it different from a pen test, a posture tool or a cloud readiness assessment?
A penetration test tries to break in and proves one path works. A posture tool, the category known as cloud security posture management, checks settings around the clock and flags drift. A cloud readiness assessment comes before a move and asks whether a workload should go to the cloud at all. That belongs with cloud migration services, not this checklist.
A cloud security assessment uses the first two as inputs, then adds what tools can't see: contracts, provider reports, incident plans, and who approves admin access. Microsoft says so about its own dashboard. Controls that can't be checked automatically show as greyed out (Microsoft Learn, updated 2026-06-17). Those still need a person.
What is Canada's CCCS cloud profile, and does it apply to private companies?
The CCCS cloud profile is a list of recommended security controls for workloads on public cloud, sorted by who's responsible under each service model. The Cyber Centre publishes it as two Excel workbooks attached to its guidance on categorising cloud services: Annex A for Low and Annex B for Medium (ITSP.50.103). Both carry the title "CCCS Cloud Security Control Recommendations (31-May-2019)".
The Medium workbook is what most people mean by the CCCS Medium Cloud Control Profile. AWS notes that it replaced the federal government's older PROTECTED B / Medium Integrity / Medium Availability (PBMM) profile in May 2020 (AWS Audit Manager docs).
Does it apply to a private company? Only if you choose to use it. ITSP.50.105 says its guidance "applies to private and public sector organizations," and ITSP.50.103 says the same. Nobody forces you. But the profile is free, it's Canadian, and it has already done the hardest part of any cloud assessment: splitting each control between you and the provider for IaaS, PaaS and SaaS. And if you sell to a federal department, it's the yardstick your buyer uses.
You can download the Medium workbook directly. Each row has a control ID in the older ITSG-33 style (AC-2(1), for example), the control text, and an X in each column it applies to.
Low or Medium: which profile fits your data?
Pick by harm, not by data type alone. These are the workbook's own examples:
CCCS Low | CCCS Medium | |
|---|---|---|
Expected harm if data leaks or the service fails | "no or limited injury" | "serious injury to an individual or organization or limited injury to a group of individuals" |
Privacy example | "Privacy violation - 1 person" | "Privacy violation - hundreds/thousands of people" |
Business examples | Minor effect on annual profit, minor loss of sale | Significant effect on annual profit, loss of major accounts, clear compliance violation |
Controls in the profile | 252 | 353 |
Controls marked for the client on SaaS | 113 | 171 |
The Cyber Centre's 2026 medium-impact profile adds industry examples: human resources, finance management, procurement, most health records processing and tax records (ITSP.10.033-01, section 2.1). If your cloud holds payroll, client files or patient data, plan for Medium.
What changed in 2026?
Three things, and they affect which document you cite.
- 2026-03-31: a new control catalogue, ITSP.10.033, replaced the ITSG-33 Annex 3A catalogue. It's adapted from NIST SP 800-53 Rev. 5 and pads control numbers, so AC-2(1) becomes AC-02(01) (ITSP.10.033).
- 2026-04-01: ITSP.10.033-01, a medium-impact profile, replaced the old PBMM profile (Annex 4A, Profile 1). It says organisations "from industry or academia" can use it and tailor it. It's a general profile, not a cloud one, and it marks the location control SA-09(05) "Not selected" (the cloud profile includes it), but selects SA-09(08), which keeps processing and storage within Canada. More on that below.
- 2026-06-19: the Cyber Centre updated its Cloud Security Assessment Program page. It now names three cloud baselines, Cloud Low (SaaS only), Cloud Medium and Cloud High, and tells readers to email contact@cyber.gc.ca for the control profiles.
So the public 2019 workbook is the best free map available, but it isn't the newest version. We couldn't find a newer public one as of 2026-10-18. If you're bidding on federal work, ask the Cyber Centre for the current profile. For everyone else, the workbook's split between provider and customer is the part you need.
Which controls are yours, and which belong to your cloud provider?
We counted this table from the Medium workbook. A control can be marked for both the provider and the client, which means it's shared. "Marked for you" doesn't mean the provider does nothing.
Control family | In the Medium profile | Marked for you on IaaS/PaaS | Marked for you on SaaS |
|---|---|---|---|
Access control (AC) | 43 | 43 | 24 |
Awareness and training (AT) | 5 | 5 | 5 |
Audit and accountability (AU) | 18 | 18 | 8 |
Security assessment and authorization (CA) | 15 | 12 | 11 |
Configuration management (CM) | 29 | 29 | 4 |
Contingency planning (CP) | 36 | 36 | 36 |
Identification and authentication (IA) | 24 | 24 | 12 |
Incident response (IR) | 19 | 18 | 18 |
Maintenance (MA) | 14 | 14 | 0 |
Media protection (MP) | 14 | 14 | 14 |
Physical and environmental protection (PE) | 22 | 0 | 0 |
Planning (PL) | 6 | 6 | 5 |
Personnel security (PS) | 9 | 9 | 9 |
Risk assessment (RA) | 10 | 10 | 3 |
System and services acquisition (SA) | 22 | 22 | 6 |
System and communications protection (SC) | 36 | 36 | 12 |
System and information integrity (SI) | 31 | 31 | 4 |
Total | 353 | 327 | 171 |
Source: CCCS Annex B workbook, counted by SMEnode on 2026-10-18.
Three things jump out.
- Physical security is never yours. All 22 physical and environmental controls sit with the provider. You can't audit a data centre yourself, so for that part you rely on the provider's audit reports (step 4 below).
- Recovery is always yours. Contingency planning (36 controls, covering backup and recovery), media protection (14), personnel screening (9) and awareness training (5) are marked for the client on every service model. SaaS included.
- SaaS moves the platform, not the people. On SaaS, configuration drops from 29 controls to 4 and system integrity from 31 to 4. Identity (12), access (24) and logging (8) stay with you.
Picture a 30-person architecture firm in Kitchener that runs on Microsoft 365. The owner assumes Microsoft handles security. Under the Medium profile, Microsoft does carry the data centres and most of the platform. But the firm still decides who gets admin rights, whether every sign-in needs MFA, how long sign-in logs are kept, and whether it could get back a project folder someone deleted three months ago. If any of those fail, that's the firm's problem. Not Microsoft's.
How do you perform a cloud security assessment?
Seven steps. They follow the Cyber Centre's own order: categorise the service (ITSP.50.103), pick a profile, assess the provider's controls and yours, then monitor (ITSP.50.105). ITSP.50.105 lists nine steps. We've added an inventory step at the front and folded the government's formal authorization steps together, since a private company doesn't need them.
Step 1: What do you actually run?
List every tenant, subscription, account and project, plus every SaaS app that holds company or client data. Put an owner's name and a purpose next to each. Then compare the list with your billing records and your single sign-on app list. Anything you pay for that isn't on the list is your first finding.
Profile control: CM-8, information system component inventory.
Step 2: How bad would a leak or an outage be?
For each service, write down the worst realistic outcome if its data leaked, was changed, or went offline for a week. ITSP.50.103 calls this security categorization and walks through four steps: build an injury table, take inventory, assess the injury, then analyse your business areas. The answer decides Low or Medium.
Profile control: RA-2, security categorization.
Step 3: Which profile and service model apply?
Match each service to Low or Medium, then to its column in the workbook: IaaS/PaaS or SaaS. A SaaS app built on a platform that's already been assessed is "stacked". In the workbook's definition, its assessment only needs to cover the controls specific to the new service. That's why a small SaaS vendor can point to its hosting provider's reports for the physical layer.
Step 4: What evidence covers the provider's half?
Ask for audit reports, then read them. The Cyber Centre is specific about which ones count (ITSP.50.105, section 2.3):
- SOC 2 Type 2 is "generally recommended" for cloud. Check that the scope covers your services, locations and dates, whether the provider relies on a subservice provider, the auditor's opinion, any testing exceptions, and the "complementary end user controls" the report expects you to run.
- SOC 3 reports "are not recommended as they do not provide enough details."
- ISO 27001 certificates only count if the scope covers the services, locations and dates you use.
- CSA STAR: prefer Level 2, third-party certification or attestation, over Level 1, which is a self-assessment.
- FedRAMP "should not be the only third-party assessment used to evaluate CSPs" in Canada.
- A CCCS assessment, where one exists. AWS, for example, lists 162 services and features in its Canadian regions as assessed and eligible up to CCCS Medium, as of 2025-09-12 (AWS).
One conflict is worth knowing about. The Cyber Centre's 2020 baseline controls for small and medium organisations tell you to require a SOC 3 report from every cloud provider (baseline control 3.10). ITSP.50.105 says SOC 3 isn't detailed enough. Both are right for their reader. A SOC 3 can be shared freely, so it's the floor for a 10-person firm. If you hold Medium-level data, ask for the SOC 2 Type 2 under a non-disclosure agreement.
Our guide on how to read a SOC 2 report shows what to look for. If you have dozens of vendors to check, that's third party risk management work.
Step 5: How do you test your own half?
Two passes. First, an automated scan of every account against a benchmark: the CIS Benchmark for your platform, plus a Canadian mapping if your tools have one (see the tools section below). Second, a manual pass for what scanners can't read: admin approvals, the leaver process, the incident plan, restore tests and contracts.
Interview the people who run it. Ask to see the last restore, not the backup schedule. Big difference.
Step 6: How do you rate and record what you find?
Rate each finding by likelihood and impact, name an owner and set a date. The profile calls the result a plan of action and milestones (CA-5), and the rating method is a risk assessment (RA-3). Our cybersecurity risk assessment guide has a method and a free template. A formal threat risk assessment maps the same work to ITSP.10.033.
Step 7: How do you stop it drifting back?
Settings change every week. Keep the automated scan running (continuous monitoring, CA-7), review findings monthly, and put the provider-report check into your contracts. ITSP.50.105 recommends that you "require continuous coverage of third-party assessments in cloud contracts (typically yearly)".
Rerun the full assessment after any big change: a new tenant, a merger, a migration, or a new SaaS app holding personal information.
Which cloud security threats should the assessment plan for?
The Cyber Centre's National Cyber Threat Assessment 2025-2026 is blunt about cloud. It says Russian state-sponsored actors "are almost certainly targeting cloud-based services with large numbers of customers in Canada." It also says attackers keep going after "a software, information technology (IT), or cloud services vendor to enable it to exploit the customers that use the service" (NCTA 2025-2026). And it notes that in July 2024, Microsoft's Azure service failed to withstand a DDoS attack, cutting access to some Microsoft services for hours.
You can't fix a state actor. You can close the ordinary gaps those threats walk through. The checklist below is built around five everyday cloud security issues:
- Stolen or reused passwords on accounts without MFA.
- Too many people with admin rights, using their everyday accounts.
- Storage, databases or admin consoles reachable from the internet.
- Logs that were never switched on, or that nobody reads.
- Backups that have never been restored, or that sit where an attacker with admin rights can delete them.
What goes on a cloud security assessment checklist?
Nine areas. Each row gives the check, the matching control in the CCCS Medium cloud profile (workbook numbering), and the evidence to keep. Add a likelihood and impact column and it doubles as a cloud risk assessment checklist.
Where the federal Cloud Guardrails add something useful, they're noted. The guardrails are 13 minimum settings that federal departments must have in place, validated and reported on "in the first 30 business days" of getting a cloud account (Treasury Board, modified 2024-01-31). They're a sensible floor for any new tenant.
Who can sign in, and with what?
Check | CCCS control | Evidence to keep |
|---|---|---|
MFA on every admin account, phishing-resistant where available | IA-2(1); Guardrail 1 | Policy export showing zero admins without MFA |
MFA on every regular user account | Guardrail 1 | Sign-in report, plus an exceptions list with reasons |
At least two and no more than five global or root administrators | AC-6(5); Guardrail 1 | Count of admin role holders |
Separate accounts for admin work, never the daily email account | AC-6(2); Guardrail 1 | List of dedicated admin accounts |
Leavers' access removed on their last day; inactive accounts disabled | AC-2(3), PS-4 | Last access review, leaver tickets |
Access granted by role, with duties split | AC-2(7), AC-5 | Role list and who can approve what |
Lockout after repeated failed sign-ins | AC-7 | Setting export |
If identity is where most of your findings land, identity and access management is a project of its own.
Do you know every account and every setting?
Check | CCCS control | Evidence to keep |
|---|---|---|
Inventory of tenants, subscriptions, accounts and SaaS apps, each with an owner | CM-8 | Inventory sheet reconciled with billing |
Written baseline settings per platform (CIS level 1 is a fair start) | CM-2, CM-6 | Baseline document and scan results |
Unused services, ports and regions switched off | CM-7 | Scan report |
Changes approved before they go live | CM-3 | Change records |
Are the right logs on, and is anyone reading them?
Check | CCCS control | Evidence to keep |
|---|---|---|
Audit, sign-in and admin activity logs on in every account and region | AU-2, AU-12 | Logging configuration export |
Logs stored where a compromised admin can't delete them | AU-9 | Log destination and its access list |
Retention period decided and set | AU-11 | Retention setting |
Alerts reach a named person, and someone reviews them | AU-6, SI-4(5) | Alert rules and review notes |
If nobody's awake at 2 a.m. to read those alerts, that's what managed security services are for.
Is your data encrypted, and who holds the keys?
Check | CCCS control | Evidence to keep |
|---|---|---|
Encryption in transit everywhere (TLS) | SC-8(1) | Policy or scan result |
Encryption at rest on storage, databases and backups | SC-28(1) | Configuration export |
Key ownership decided: provider-managed or your own keys, and who can use them | SC-12, SC-13 | Key inventory and access list |
Data deleted or sanitised when you leave a provider | MP-6 | Contract clause, provider deletion statement |
What can reach your cloud from the internet?
Check | CCCS control | Evidence to keep |
|---|---|---|
Network rules deny by default and allow by exception | SC-7(5) | Security group or firewall rule export |
Storage and databases private unless they're meant to be public | SC-7, AC-3 | Public exposure scan |
Admin and remote access only through controlled paths (VPN, bastion host, just-in-time access) | AC-17, SC-7 | Access path diagram |
Could you restore last Tuesday's data?
Check | CCCS control | Evidence to keep |
|---|---|---|
Backups on a defined schedule (the profile's wording is "daily incremental; weekly full") | CP-9 | Backup job report |
Restores tested, with dates and results | CP-9(1), CP-4 | Restore test log |
A backup copy kept separate from the production environment | CP-9(3) | Backup location and who can delete it |
A written recovery plan with target times | CP-2, CP-10 | Plan, last review date |
How fast do you find and fix weaknesses?
Check | CCCS control | Evidence to keep |
|---|---|---|
Vulnerability scans of VMs, containers and images on a schedule | RA-5, RA-5(2) | Scan history |
Patches tracked to closure | SI-2, SI-2(2) | Patch report with ages |
Someone subscribed to Cyber Centre alerts and vendor advisories | SI-5 | Subscription and who reads it |
Who does what when something goes wrong?
Check | CCCS control | Evidence to keep |
|---|---|---|
An incident plan that names your provider's support and security contacts | IR-8 | Plan with contacts |
The plan rehearsed (a tabletop exercise counts) | IR-3 | Exercise notes |
A breach reporting path. PIPEDA requires a report to the Privacy Commissioner when a breach creates "a real risk of significant harm" (PIPEDA s.10.1) | IR-6 | Breach log and decision records |
A plan for data spilled into the wrong place | IR-9 | Procedure |
Have you checked the provider, and where it keeps your data?
Check | CCCS control | Evidence to keep |
|---|---|---|
Provider audit reports reviewed every year | SA-9 | Review notes per provider |
Security terms in the contract: breach notice, audit rights, deletion at exit | SA-4, SA-9 | Contract clauses |
Data location decided and written down per service | SA-9(5) | Region list per service |
Provider staff with access screened (look for it in the SOC 2 or CCCS report) | PS-7 | Report section reference |
Where should your cloud data live under Canadian law?
Here's where the profile and the law part ways. In the CCCS Medium cloud workbook, control SA-9(5) restricts processing and storage to locations in Canada, citing a Treasury Board direction on data residency. That's a federal government rule. The 2026 general medium profile marks SA-09(05) "Not selected" but selects SA-09(08), which keeps processing and storage within Canada (ITSP.10.033-01).
For a private company, the law is about responsibility, not geography.
- PIPEDA doesn't name a country. An organisation "is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing," and must "use contractual or other means to provide a comparable level of protection" (PIPEDA, Schedule 1, clause 4.1.3).
- Quebec's private-sector act goes further. Before personal information leaves Quebec, a business "must conduct a privacy impact assessment," and the transfer "must be the subject of a written agreement." The same applies when you hand a provider outside Quebec the job of keeping that information for you (P-39.1, s.17).
So a Canadian cloud region isn't automatically a Quebec one. If you hold Quebec residents' data, check which city your region sits in, and do the privacy impact assessment before you move anything. Our Quebec Law 25 compliance and PIPEDA compliance work covers the contracts and records side.
Federal departments have one more layer: Guardrail 5, data location, in the same Treasury Board guardrails.
Which cloud security assessment tools map to the CCCS profile?
You don't need to buy anything to start. The big platforms already ship Canadian mappings.
- Microsoft Defender for Cloud lists "Canada Federal PBMM 3.2020" among its regulatory compliance standards, for Azure, AWS and GCP resources (Microsoft Learn). Controls it can't check automatically show greyed out, so treat the score as a partial picture.
- AWS Config has a sample conformance pack, "Operational Best Practices for Canadian Centre for Cyber Security (CCCS) Medium Cloud Control Profile", that maps profile controls to Config rules (AWS). AWS is clear that sample templates don't guarantee compliance on their own.
- AWS Audit Manager also had a CCCS Medium framework, but the service moved to maintenance mode and can't be set up in new accounts from 2026-04-30 (AWS).
- CIS Benchmarks are hardening guides for AWS, Azure, Google Cloud and Microsoft 365, among others (CIS). Check that the version your tool uses matches the current benchmark.
Those tools grade settings. They don't read contracts, test restores, or decide whether data should be in that region at all. That's the gap between a dashboard and a cloud security assessment.
If you'd rather hand off the scanning, the scoring against the Canadian profile and the drift tracking, that's what our cloud security services cover. It's ongoing work, not a one-off report.
What are the 6 pillars of cloud security?
There's no official list. Vendors publish different sixes. And the best-known six pillars in cloud, from AWS's Well-Architected Framework, aren't a security list: they're operational excellence, security, reliability, performance efficiency, cost optimization and sustainability (AWS). Security is one of the six.
The six areas most cloud security lists share map neatly onto the CCCS families:
Pillar | What it covers | CCCS families |
|---|---|---|
Identity and access | Who can sign in, and with what rights | AC, IA |
Data protection | Encryption, keys, deletion | SC-8, SC-12, SC-13, SC-28, MP |
Network security | What's reachable, and from where | SC-7, AC-17 |
Monitoring and detection | Logs, alerts, review | AU, SI-4 |
Configuration and vulnerability management | Baselines, drift, patching | CM, RA-5, SI-2 |
Incident response and recovery | Plans, backups, restores | IR, CP |
Governance sits under all six: planning (PL), assessment (CA) and vendor management (SA).
What are the four types of cloud security?
Again, there's no single answer. You'll usually see one of two lists.
- Four types of control: deterrent, preventive, detective and corrective.
- Four ways to run cloud: public, private, hybrid and multi-cloud.
For an assessment, a third split matters more: the service model. IaaS, PaaS or SaaS decides how many controls are yours (327 versus 171 in the Medium profile), so that's the split to get right first.
What are the three main types of security assessments?
The usual three are a vulnerability assessment, a penetration test and a risk assessment.
- A vulnerability assessment finds known weaknesses at scale, usually with scanners. That's control RA-5, and the ongoing version is vulnerability management.
- A penetration test proves whether a weakness can actually be exploited, by trying. See penetration testing.
- A risk assessment weighs likelihood and impact so you fix the right things first. That's RA-3.
A cloud security assessment borrows from all three: scan results, sometimes a targeted test, and a risk rating on every finding.
How often should you run a cloud security assessment?
A full assessment once a year, automated checks all the time, and a rerun after any major change. That lines up with the Cyber Centre's guidance: yearly third-party report coverage for providers, and continuous monitoring that "generally includes the periodic assessment of security controls (preferably automated)" (ITSP.50.105).
For a brand-new tenant, borrow the federal deadline. Get the guardrail basics done within 30 business days of opening the account.
Should you run it yourself or bring in help?
Do it yourself if you have one tenant, mostly SaaS, no government buyers, and someone who can read a policy export. This checklist and the built-in tools will cover a lot of ground.
Bring in outside cloud security assessment services when:
- You sell to a federal or provincial government, or to a buyer who asks for CCCS, Protected B or SOC 2 evidence.
- You run more than one cloud, or IaaS with your own networks and virtual machines.
- Your data is Medium by the profile's own examples: payroll, client financials, health records.
- You've just finished a migration and nobody has scored the result. Our guide to managed cloud services covers what to hand off and what to keep.
Honestly, the hardest part isn't the scan. It's the manual half: proving restores, matching provider reports to your gaps, and writing it all down so an auditor or a buyer accepts it.
What if a government buyer asks for a CCCS assessment?
Picture a 25-person Montreal software company whose app a federal department wants to buy. The department's security team asks for "the CCCS assessment". Here's what the program page says that involves:
- The program assesses the provider's side only, "the security controls that fall within the direct responsibility of the vendor."
- Enterprise services bought centrally for most departments (Microsoft 365 is the page's example) get an enterprise assessment led by the Cyber Centre. Single-use SaaS bought by one department gets a local assessment led by that department, with Cyber Centre checkpoints.
- Evidence is validated by third-party assessment organisations (3PAOs). For now the list is limited to FedRAMP-accredited firms, and the Cyber Centre is working with the Standards Council of Canada on a Canadian accreditation program.
- The baseline is Cloud Low (SaaS only), Cloud Medium or Cloud High, picked by how sensitive the data is.
So the company's preparation is this checklist run against the Medium workbook, a SOC 2 Type 2 if it has one, and its hosting provider's own assessment for the stacked layer. Our Ottawa cybersecurity page explains how we map that work to ITSG-33. We also support teams in Toronto and Montreal.
What should you do this week?
Three things you can do without buying anything:
- Download the Medium workbook and filter the client column for your main service model, IaaS/PaaS or SaaS. That's your real list.
- Count your global admins and check every one has MFA. If there are more than five, fix that first.
- Restore one file or mailbox from backup and time it.
Then run the seven steps. Bottom line: the Canadian profile already tells you which half of cloud security is yours, so the assessment is mostly about proving that half works. If you'd like a senior engineer's read on your results, talk to SMEnode. We'll tell you plainly whether you need help or just need to finish the checklist.
