Control Parameters in ITSG-33 and ITSP.10.033: The Values That Decide What a Control Actually Requires

Open any control catalogue at a random page and you will find sentences with holes in them.

Retain audit records for [Assignment: organization-defined time period]. Automatically [Selection (one or more): lock the account or node …; notify system administrator] when the maximum number of unsuccessful attempts is exceeded. The control tells you what to do. The bracket tells you that somebody still has to decide how much.

Those brackets are organization-defined parameters, and on most projects they are filled in last, by whoever is assembling the security plan, under deadline. That is backwards. The bracket is not an administrative gap in the control — it is the part of the control that carries the risk decision.

A control with an empty bracket cannot be implemented and cannot be assessed. Nobody knows what it asks for yet.

What the Brackets Are#

Catalogues have to serve an air-gapped system and a multi-tenant cloud tenancy from the same sentence. Rather than write a control per environment, the catalogue leaves the environment-dependent quantity open. ITSP.10.033 describes the mechanism directly:¹

For some controls and activities, additional flexibility is provided by allowing organizations to define specific values for designated parameters. Flexibility is achieved as part of a tailoring process using assignment and selection operations embedded within the controls and activities and enclosed in brackets.

ITSP.10.033 — Concepts and structure

Two things in that sentence are worth pausing on.

First, parameter-setting is tailoring. It is not a step that happens after tailoring; it is one of the moves tailoring consists of, alongside scoping and compensating controls — the subject of profile selection and tailoring.

The mechanism is not new. ITSG-33's control catalogue used the same bracketed assignment and selection operations, and ITSP.10.033 carries them forward — so a parameter resolved under the older catalogue transfers conceptually intact.⁵

Second, the flexibility is bounded. Assignment and selection behave differently.

Scroll sideways to see the full diagram →

The catalogue states the distinction plainly: "In contrast to assignment operations, which allow complete flexibility in the designation of parameter values, selection operations narrow the range of potential values by providing a specific list of items for organizations to choose from."¹

The two also nest. AC-7 lets you choose what happens once the attempt limit is exceeded, and the first option on its menu — "lock the account or node for [Assignment: organization-defined time period]" — hands you an assignment inside the selection you just made.² Picking an option does not always finish the job.

And the values do not sit beside the control once chosen. They join it:¹

Once specified by the organization, the values for the assignment and selection operations become a part of the control or activity. […] The implementation of the control or activity is assessed for effectiveness against the completed control or activity statement.

ITSP.10.033 — Concepts and structure

That last clause is the assessor's whole basis. An assessment tests the completed statement — control plus your values. Which means an unfilled bracket is not a documentation gap. It is an untestable control.

Why the Values Carry the Risk#

They are the engineering specification. "Terminate inactive sessions" tells an identity engineer nothing actionable. Fifteen minutes tells them what to configure on the gateway, the reverse proxy and the application. The parameter is the point at which a policy sentence becomes something a person can build and a scanner can check.

They are where risk tolerance is set. Locking an account after three failed attempts and locking it after ten are the same control, AC-7, and materially different exposures to credential stuffing. Nobody records "we accepted more brute-force risk" — they record a number in a spreadsheet cell. The decision happens either way. Parameters are where an organization's risk appetite gets expressed in units, which is why they belong to the profile authority and not to whoever is finishing the paperwork.

They are what makes enforcement automatable. A policy engine cannot evaluate prose. It can evaluate "idle timeout ≤ 15 minutes." Populated parameters are the boundary values that automated assertions are written against, which is the only way a control stays true between assessments rather than only on the day it was tested.

What a Parameter Record Looks Like#

Below is the shape of a resolved parameter set — a worked example, not a baseline.

Note what the last row does. Where a parameter is set by a policy instrument rather than by the project, the record says so and points at the instrument. That is a resolved parameter, not an unfilled one — the value exists, it simply is not yours to choose.

Where Parameter Governance Breaks#

Three failure modes, all common.

The value ages out of the document. Parameters are recorded in a security plan to get an authorization, then production moves on. Six months later the gateway timeout is sixty minutes because an operational ticket changed it, and the document still says fifteen. Nothing detected the divergence because nothing was watching.

Every project decides independently. Without a departmental baseline, one team picks a fifteen-minute lockout and another picks sixty, for identical data at identical sensitivity. The department now has a security posture that varies by which team read which template, and no one can describe it in a sentence.

Inheritance is assumed rather than checked. A team marks a control inherited from a shared platform and stops. The platform's value may be weaker than the team's requirement, and the identifier gives no hint of it. ITSP.10.033 addresses this directly:¹

An inheriting entity cannot assume that controls or activities are the same and mitigate the appropriate risk to the system just because the identifiers (e.g., AC-01) are the same. It is essential to examine the parameters (e.g., assignment or selection operations) when determining if a common control or activity is adequate to mitigate system-specific risks.

ITSP.10.033 — Concepts and structure

Comparing parameters is the work. The identifier match is what makes people skip it.

Governing Them#

Decide once, at the right altitude#

Most parameters should never reach a project team. Organize them in tiers.

Scroll sideways to see the full diagram →

1. Departmental baselineset by the security authority; projects consume, not choose
2. Shared platformvalues delivered by a common service, published to consumers
3. System-specificthe residue that genuinely depends on this application

The point of the hierarchy is subtraction. A project that inherits two hundred settled values and decides fifteen can give those fifteen real thought. A project facing all two hundred will fill them from a template and mean none of them.

The American baselines make the same division of labour visible from the other side: SP 800-53B decides which controls belong in a low, moderate or high baseline, and leaves their parameter values to the adopting organization.⁴ Choosing the controls and resolving their values are two separate jobs, and only the second is unavoidably yours.

The catalogue supports this reading: parameters "may be derived from many sources, including laws, Orders in Council, policies, directives, regulations, jurisprudence, standards, guidance, and mission or business needs," with organizational risk assessments and risk tolerance as further factors.¹ Most of those sources sit above any single system.

Treat a change as a change#

A parameter value is a configuration item. Relaxing lockout from three attempts to ten alters the system's exposure, and it should travel the same path as any other change — under CM-3 Configuration Change Control, with the impact considered under CM-4 Impact Analyses.² A proposed change needs a stated rationale, a security review, and a judgment about whether it disturbs the basis of the current authorization.

The test is simple: if the value was worth recording in the authorization package, it is worth a decision to change.

Watch the live value, not the document#

An annual review confirms a parameter was correct on one day a year. Codify the authorized values into deployment templates and policy engines so the environment is built from them, and alert on divergence so the gap between authorized and actual becomes an event rather than a discovery. Where divergence is not immediately fixable, it belongs in the plan of action and milestones like any other open gap — see continuous monitoring.

Keep them somewhere structured#

Parameters buried in prose cannot be compared, inherited, diffed or checked. Held as structured data, they can: a project can consume the departmental baseline directly, an assessor can test evidence against an authoritative value rather than a retyped one, and a catalogue update can be diffed against what you have rather than re-read from scratch.

Where CtrlFort Fits#

A parameter's value is easy to record and hard to keep — it is one cell in one document, and every copy of it drifts independently.

CtrlFort Assess keeps the framework and its controls as the objects the assessment is built on, and Control Intelligence carries for each control its objective, assessment criteria, expected evidence and the assurance activities to perform. That is where a resolved requirement belongs: attached to the control being assessed, not in a file beside it. Because requirements, controls, evidence and determinations are separate linked objects, an authorizer can follow the chain from the profile through to a determination, and the assessment intelligence architecture keeps that chain consistent across every system assessed against the same profile.

Choosing fifteen minutes over sixty remains a human judgment about risk, and it should. What the platform removes is the version of the problem where the judgment was made properly and then lost.

Final Thoughts#

Parameters look like the least interesting part of a control catalogue, which is exactly why they go unexamined. They are also the only part that says how much — and "how much" is the whole of the protection.

Settle them high, attach them to the control, compare them before trusting an inherited one, and watch the running value rather than the recorded one. A control set governed that way describes a system that actually exists.

Previous: What Makes a Security Control Mandatory · Next: ITSP.10.033 vs NIST SP 800-53

Frequently Asked Questions#

What is an organization-defined parameter?#

It is a bracketed placeholder inside a control statement that the adopting organization must resolve — either an assignment, where you supply a value such as a duration or count, or a selection, where you choose from a list the catalogue provides. ITSP.10.033 describes both as operations within the tailoring process.

Does the Cyber Centre publish standard parameter values for Protected B systems?#

Not as a universal table. ITSP.10.033-01 suggests a profile of controls and activities and states that it is a starting point requiring tailoring to each department's context. Your department's own profile is the authority for your systems; treat any table of values you find elsewhere, including this one, as illustrative.

Can a parameter value be changed after authorization?#

Yes, through change control. The value is part of the assessed control statement, so a change alters what was authorized. Handle it under configuration change control with an impact analysis, and confirm whether the change affects the basis of the current authorization decision.

If a control is inherited, do I still need to care about its parameters?#

Yes, and this is the most consequential answer on the page. ITSP.10.033 states that an inheriting entity cannot assume a common control is adequate just because identifiers match, and that parameters must be examined. A platform's ninety-minute timeout does not satisfy your fifteen-minute requirement, however well the control numbers line up.

Why do ITSP.10.033 identifiers look different from NIST's?#

ITSP.10.033 zero-pads them — AC-01 where NIST writes AC-1. The controls correspond; only the notation differs. It matters when matching identifiers across catalogues programmatically.

References#

1. Security and privacy controls and assurance activities catalogue (ITSP.10.033) — Concepts and structure ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033/concepts-structure
2. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5) ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
3. Suggested organizational security and privacy control and activity profile — Medium impact (ITSP.10.033-01) ↩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
4. Control Baselines for Information Systems and Organizations (SP 800-53B) ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final
5. IT security risk management: A lifecycle approach (ITSG-33) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/it-security-risk-management-lifecycle-approach-itsg-33