CPCSC Level 1 Control
03.01.01Access control

CPCSC 03.01.01: Account management

Create, authorize, review, monitor, and disable accounts that can access systems containing specified information. This guide separates the formal control language from practical implementation, evidence, auditor questions, and related controls.

Formal Control Language

Official CPCSC Level 1 wording for 03.01.01. Use the Government of Canada page as the source of truth for certification or procurement submissions.

  • System account types allowed and specifically prohibited are defined.
  • System accounts are created, enabled, modified, disabled, and removed in accordance with policy, procedures, prerequisites, and criteria.
  • Authorized users of the system, group and role membership, and access authorizations and other attributes are specified.
  • Access to the system is authorized based on a valid access authorization, intended system usage, and other attributes required by the organization or associated missions and business functions.
  • System account use is monitored.
  • System accounts are disabled when accounts have expired, are no longer associated with a user or individual, are in violation of organizational policy, or have been identified as a significant risk.
  • Managers and defined roles are notified when accounts are no longer required, when users are terminated or transferred, and when system usage or need-to-know changes.
  • Users are required to log out when the organization-defined time period of expected inactivity or description of when to log out is met.

Contains information sourced from Government of Canada material used under the Open Government Licence - Canada.

What This Means In Plain English

Know who has access, why they have it, what role they are in, and when that access should be removed.

This control is not just an IT user list. It is the operating discipline around joiners, movers, leavers, admins, contractors, shared tools, and in-scope systems.

For CPCSC Level 1, the useful test is not whether a policy mentions the control. The useful test is whether an owner can show the system setting, record, ticket, review output, or operating routine that proves the answer is true today and can be repeated when the next contract, customer, or assessment request arrives.

How To Implement It

1

Create an approved account inventory for email, identity provider, cloud storage, source code, ticketing, endpoint management, VPN, and any system that stores or processes specified information.

2

Assign one owner for account changes, usually IT, the security owner, or the operations lead. Require manager approval for new access and document privileged access separately.

3

Run a scheduled access review at least quarterly for in-scope systems. For small teams, a spreadsheet export with owner sign-off is enough if it is current and repeatable.

4

Tie HR or contractor offboarding to account disablement. Include a same-day disable target for terminated users and a review of groups, shared drives, keys, tokens, and admin rights.

5

Set inactivity lockout or session timeout for systems where specified information is accessed, especially cloud apps, laptops, and remote access paths.

Evidence Normally Gathered

Current user export from the identity provider or key applications.

Role, group, or permission mapping for in-scope systems.

Access request and approval tickets.

Quarterly access review record with owner sign-off.

Offboarding checklist showing accounts disabled or removed.

Admin account list and exception notes.

Session timeout or inactivity settings screenshots.

Common Auditor Questions

How do you know this list includes every account that can access specified information?

Who approves new access and privileged access?

How often do you review whether access is still needed?

Show me a recent offboarding example and how access was removed.

What happens if a manager does not respond to an access review?