Security Assessment

Beyond Checklists: Consistent, Repeatable and Reliable Security Assessments

A gated departmental process for on-premises systems — and where ITSP.10.033 assurance activities fit

Security AssessmentGovernment of CanadaRisk & Compliance

Organizations often view security assessments as a compliance exercise focused on producing reports and closing findings. In reality, a well-executed assessment should provide a clear understanding of a system's security posture, identify meaningful risks, and support informed authorization decisions.

The difference between those two things is not effort. It is method. Two assessors given the same system, the same control profile and the same week will reach different conclusions unless something in the process forces them not to.

Why Assessments Need Structure#

Without a defined methodology, assessments vary significantly depending on the assessor, the available evidence, or stakeholder expectations. This leads to inconsistent recommendations, unclear risk statements, and difficulty comparing results across systems.

A gated assessment process introduces discipline into the assessment lifecycle. It ensures that each assessment progresses through clearly defined stages, with quality checkpoints before advancing to the next phase.

The ultimate objective is simple:

Assess → Validate → Identify Gaps → Determine Risk → Support Authorization

This is not a new idea in the Government of Canada. ITSG-33 Annex 2 already builds assess-then-approve pairs into every phase of the system development life cycle — Assess High-Level Design then Approve High-Level Design, Assess Integration Security Testing then Approve Production Installation, and so on.3 A departmental gated process applies the same discipline to a single assessment engagement.

Where ITSP.10.033 Fits#

On 31 March 2026, ITSP.10.033, Security and privacy controls and assurance activities catalogue took effect, superseding ITSG-33 Annex 3A.1 The name matters: it is a catalogue of controls and assurance activities, and the second half is what an assessment methodology is built on.

[An assurance activity is] a collection of tasks that increases the confidence that a security or privacy control is appropriately designed and implemented and is operating as intended.

ITSP.10.033

Read that definition slowly, because it is the whole argument of this article in one sentence. Three conditions — designed, implemented, operating as intended — and a policy document satisfies only the first.

What an assurance activity has to establish Three stacked levels. One, designed: the control is specified and approved, evidenced by policy, standard, an SSP section or an approved design. Two, implemented: the control exists in the running system, evidenced by a configuration export, screenshot, infrastructure-as-code template or demonstration. Three, operating as intended: the control keeps working and someone would notice if it stopped, evidenced by logs over a period, ticket history, review records or test results. A control is not demonstrated until all three hold; documentation alone stops at the first. WHAT AN ASSURANCE ACTIVITY HAS TO ESTABLISH A control is not demonstrated until all three hold. Documentation alone stops at the first. 1 Designed The control is specified and approved EVIDENCE · POLICY, STANDARD, SSP SECTION, APPROVED DESIGN 2 Implemented The control exists in the running system EVIDENCE · CONFIGURATION EXPORT, SCREENSHOT, IAC TEMPLATE, DEMONSTRATION 3 Operating as intended The control keeps working, and someone would notice if it stopped EVIDENCE · LOGS OVER A PERIOD, TICKET HISTORY, REVIEW RECORDS, TEST RESULTS
Figure 1: The three things an assurance activity has to establish, and the evidence that establishes each.

Scroll the diagram sideways to see every profile →

Three further changes in ITSP.10.033 are worth knowing before you scope Gate 2:

ChangeWhat it means for an assessment
Assurance items are activities, not controlsITSP.10.033 states plainly: "We refer to assurance-related 'controls' as activities, rather than controls." Assessment findings should follow the same vocabulary.
Three new familiesPM (Program Management), PT (Personal Information and Transparency) and SR (Supply Chain Risk Management) widen the scope of a full assessment.
Canadian enhancements start at 400Enhancements such as SA-400 and IA-04(400) are Canadian additions, numbered to avoid collision with NIST. Do not expect to find them in SP 800-53.
Adapted from NIST SP 800-53 Rev. 5The catalogue aligns with SP 800-53 Rev. 5, reflecting Canadian business and legislative requirements.16

The Gated Assessment Process#

The departmental security assessment gated process Six sequential gates, each a checkpoint before the next begins. Gate 0 Initiation and readiness establishes scope, categorization and the authorization boundary. Gate 1 System understanding covers architecture, data flows and trust boundaries. Gate 2 Control assessment gathers evidence against each control. Gate 3 Validation and gap analysis confirms findings with stakeholders. Gate 4 Risk and remediation produces residual risk statements. Gate 5 Reporting and authorization produces the report, the plan of action and milestones, and the risk decision. The whole process rests on three principles: consistent, repeatable and reliable. The objective chain runs assess, validate, identify gaps, determine risk, support authorization. THE DEPARTMENTAL SECURITY ASSESSMENT GATED PROCESS Assess Validate Identify gaps Determine risk Support authorization 0 GATE Initiation & Readiness Scope and boundary 1 GATE System Understanding Architecture and data flows 2 GATE Control Assessment Evidence per control 3 GATE Validation & Gap Analysis Findings confirmed 4 GATE Risk & Remediation Residual risk statements 5 GATE Reporting & Authorization Report, POA&M, decision Consistent Repeatable Reliable Every gate closes only when its evidence is in hand — that is what makes the next one meaningful.
Figure 2: Six gates, each closing on its own evidence before the next opens.

Scroll the diagram sideways to see every profile →

Gate 0 — Initiation & Readiness#

Every assessment starts with understanding what is being assessed. At this stage the assessment team:

  • Identifies the system owner and stakeholders
  • Defines the assessment scope
  • Confirms the security categorization
  • Establishes the authorization boundary
  • Collects required documentation

Common artifacts include:

  • System Security Plan (SSP)
  • Architecture diagrams
  • Network diagrams
  • Asset inventories
  • Policies and procedures
  • Previous assessment reports
  • Vulnerability scan results

The goal is to ensure the assessment begins with sufficient information and a clearly defined scope.

Gate 1 — System Understanding#

Once the assessment is initiated, the team develops an understanding of the environment. Key activities include:

  • Kick-off meeting with stakeholders
  • Architecture review
  • Data flow review
  • Trust boundary identification
  • Technology stack analysis
  • Identification of external dependencies

This phase establishes the context required to properly evaluate security controls and understand how the system supports business operations.

Gate 2 — Control Assessment#

This is the core assessment phase. Assessors review and validate the implementation of applicable security controls through:

  • Documentation review
  • Configuration reviews
  • Technical demonstrations
  • Interviews
  • Walkthroughs
  • Evidence collection

Controls are assessed against established requirements and documented as:

ResultMeaning
MetThe control is implemented and operating as required
Partially MetThe control is in place but incomplete or inconsistently applied
Not MetThe control is absent, or evidence does not demonstrate it
Not ApplicableThe control does not apply to this system or deployment

A critical principle during this stage:

Policy statements alone do not demonstrate compliance. Controls must be supported by objective evidence showing implementation and operational effectiveness.

Gate 3 — Validation & Gap Analysis#

After the initial review, assessors work with system stakeholders to validate findings and resolve outstanding questions. Activities typically include:

  • Technical workshops
  • Follow-up interviews
  • Demonstrations of security capabilities
  • Collection of additional evidence
  • Validation of control implementation

The objective is not to find fault but to ensure that conclusions are accurate and evidence-based. This stage often results in updates to initial findings as additional evidence becomes available.

Gate 4 — Risk & Remediation#

Once gaps have been confirmed, focus shifts from controls to risk. Assessment teams evaluate:

  • Threats
  • Vulnerabilities
  • Business impact
  • Likelihood
  • Existing safeguards
  • Compensating controls

The outcome is a set of residual risk statements that clearly describe:

  • What the risk is
  • Why it exists
  • Potential business impact
  • Recommended mitigation actions

This phase transforms technical findings into information that can be understood and acted upon by management.

Gate 5 — Reporting & Authorization#

The final stage is reporting and decision support. Assessment results are consolidated into:

  • Final assessment reports
  • Risk summaries
  • Recommendation packages
  • Plans of Action and Milestones (POA&M)

These deliverables provide decision-makers with the information necessary to determine whether risks can be accepted, mitigations are required, or additional assessment activities are necessary.

The assessment concludes when leadership has sufficient information to make an informed risk decision — which is also how ITSG-33 Annex 2 frames it, with authorization resting on an acceptable level of residual risk determined through a residual risk assessment.3

The Assessment Lifecycle#

  1. Gate 0 — Initiation & ReadinessScope, categorization, authorization boundary
  2. Gate 1 — System UnderstandingArchitecture, data flows, trust boundaries
  3. Gate 2 — Control AssessmentEvidence gathered against each applicable control
  4. Gate 3 — Validation & Gap AnalysisFindings confirmed with stakeholders
  5. Gate 4 — Risk & RemediationResidual risk statements with business impact
  6. Gate 5 — Reporting & AuthorizationReport, POA&M, informed risk decision

Conclusion#

An effective departmental security assessment program is not measured by the number of controls reviewed or findings documented. Its value lies in producing assessments that are consistent, repeatable and reliable.

By following a structured gated process, organizations can improve assessment quality, reduce variability, strengthen risk decisions, and provide greater confidence to stakeholders responsible for authorizing and operating critical systems.

The result is a practical assessment methodology that moves beyond compliance and focuses on what truly matters: understanding and managing risk.

Frequently Asked Questions#

What is an assurance activity in ITSP.10.033?#

ITSP.10.033 defines it as "a collection of tasks that increases the confidence that a security or privacy control is appropriately designed and implemented and is operating as intended." The publication also renames assurance-related items from "controls" to "activities" — a deliberate vocabulary change that assessment findings should follow.

Does ITSP.10.033 tell me how to run an assessment?#

No. It says it creates "a foundation for developing assessment methods and procedures to determine the effectiveness of security and privacy controls." It does not define examination methods, result terminology, or when a finding becomes a risk statement. Those remain departmental decisions, which is why a documented methodology matters.

Why isn't a policy enough to close a control?#

Because a policy establishes only that a control is designed. An assurance activity has to establish that it is also implemented and operating as intended. A password standard does not prove that the password policy is enforced on the running domain controller, and neither proves it stayed enforced last quarter.

What changed when ITSP.10.033 replaced ITSG-33 Annex 3A?#

The catalogue is now adapted from NIST SP 800-53 Rev. 5, adds the PM, PT and SR families, numbers Canadian-specific enhancements from 400 upward, and treats assurance items as activities rather than controls. ITSG-33's lifecycle annexes were not withdrawn — only Annex 3A, the control catalogue, was superseded.

How many gates should a departmental process have?#

The number matters far less than whether each gate has an exit condition somebody can check. Six works because each one produces a distinct artifact — scope, system understanding, control results, validated findings, risk statements, and a decision package. Merging Gates 2 and 3 is the most common shortcut, and it is the one that most often produces findings a system owner successfully disputes after the report is issued.

Where does the POA&M come from?#

Gate 5, built from the confirmed gaps of Gate 3 and the risk statements of Gate 4. A POA&M assembled from raw Gate 2 output tends to list control failures rather than risks, which gives management a task list instead of a decision.

References#

  1. 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
  2. Cyber security and privacy risk management: A lifecycle approach Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management
  3. ITSG-33 Annex 2 — Information System Security Risk Management Activities Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
  4. 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
  5. ITSP.10.033-01 — Suggested organizational security and privacy control and activity profile, Medium impact Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/suggested-organizational-security-privacy-control-activity-profile-medium-impact-itsp10033-01
  6. NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  7. NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls in Information Systems and Organizations National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/53/a/r5/final
On this page

Zeeshan Mahmood

Security Assessment, Architecture & AI

Zeeshan is a security advisor and senior IT security risk analyst who works at the seam between assessment and design. He runs the full authorization lifecycle — security categorization, threat and risk assessment, control profile selection, and the evidence behind an authority to operate — and designs the solution, cloud and security architecture that has to survive it, from landing zones and network segmentation to Zero Trust and cross-domain solutions. His current focus includes AI security and the assessment of AI-enabled systems. He holds CISSP, CCSP, CISM, CKS and Azure Solutions Architect Expert, and leads assurance methodology at CtrlFort.

Run this framework against your own control library.

CtrlFort Assess maps cloud control profiles, ITSG-33 baselines and certification regimes to one shared evidence base — so a control you evidence once satisfies every obligation it maps to.