How to Scope Canada's Baseline Cyber Security Controls

Establish organizational context before selecting controls. The Canadian Centre for Cyber Security's Baseline Cyber Security Controls for Small and Medium Organizations, Version 1.2, places “Organizational Controls” before “Baseline Controls.” That order offers a useful discipline: determine whether the guidance fits the environment, then decide how its controls apply.

The baseline has a front door

The Canadian baseline was written for small and medium organizations seeking practical recommendations for improving resilience through cybersecurity investment.

Its intent is deliberately practical. The publication describes an 80/20 approach: a condensed set of measures intended to help smaller organizations gain meaningful benefit from manageable effort. It also gives an important limitation. The guidance is not comprehensive or all-encompassing, and system owners remain responsible for risks associated with their environments.

That limitation changes how the document should be used. The baseline can provide a useful starting point, but it should not be applied as an identical checklist to every organization. Section 2 establishes context that helps determine whether the baseline fits; Section 3 then presents the controls.

Six facts to establish before selecting controls

1. Organizational fit

The publication is intended for Canadian organizations with fewer than 500 employees. Headcount is useful, but it does not establish risk by itself. A small organization can still operate critical services, hold sensitive information or face contractual and sector-specific obligations.

2. Systems and assets in scope

The source recommends considering the information systems and assets used to conduct business: computers, servers, network and mobile devices, applications, services and cloud applications. This includes technology that is owned, contracted or otherwise used.

If something is excluded, record the rationale and recognize the risk accepted by doing so. Outsourcing a service does not automatically remove it from the organization's security scope.

3. Potential injury

The publication asks organizations to consider potential injury to confidentiality, integrity and availability. What could happen if sensitive information were disclosed, important information were changed without authorization, or a system or service became unavailable?

The baseline was designed for circumstances in which potential injuries remain at or below the publication's medium level. It recommends more comprehensive measures where potential injury is higher.

4. Primary cyber threat

The baseline was designed around cybercrime as the threat most likely to affect Canadian small and medium organizations. That assumption may not fit every environment. Organizations in strategic sectors, those holding commercially sensitive intellectual property, or those supporting public or national security may need to consider more advanced threats and broader measures.

5. Leadership responsibility

The source recommends identifying a person in a leadership role who is specifically responsible for IT security. That accountability should be clear enough that the organization knows who can approve priorities, accept exclusions and decide when additional action is required.

6. Investment and capacity

Section 2 also asks organizations to understand their IT and security spending, staffing and capacity, and to commit to progressive improvement. Capacity affects which controls can be operated reliably, which services may need external support and how quickly gaps can be addressed.

Four working questions for leaders

ByteDefender translates this context into four practical questions. They are a working interpretation, not a replacement for the publication's complete organizational assessment.

1. What are we protecting?

Start with business services, then identify the systems, information and providers that support them. A useful scope record includes the service or process, supporting technology, information handled, internal owner, inclusion status, and the rationale and risk owner for any exclusion.

Starting with business services avoids a common mistake: producing a technically accurate asset list that does not explain what the organization depends on.

2. What harm could a loss cause?

Describe consequences in operational terms before assigning a generic risk label. Consider who could be harmed by disclosure, which decisions or transactions could be affected by unauthorized change, and how long the organization could operate without the service or data.

The answer may differ across confidentiality, integrity and availability. A service may tolerate several hours of downtime while an unauthorized change to the information it carries could have a much more serious consequence.

3. Who owns the decision?

Separate accountability from implementation. A leadership owner should be able to approve scope, priorities, risk acceptance and investment. Technical staff or service providers may own individual actions and evidence. An external provider can operate a control, but the organization still needs an internal person who decides whether the service, evidence and remaining risk are acceptable.

4. What is already in place—and how do we know?

This fourth question is ByteDefender's operational extension of the source, not wording taken directly from Section 2. Before selecting new work, record each relevant control as implemented, partially implemented, absent or unknown. Capture its owner, current evidence, latest verification date, next action and next review date.

Evidence might be a configuration report, a completed restoration test, an incident-exercise record or another artifact that demonstrates current state. A policy stating that something should happen is not necessarily evidence that it does happen. “Unknown” is also useful: it identifies where verification is needed without treating an assumption as a working control or confirmed gap.

Do not compress fit and threat into a checklist

The four questions make the discussion easier to run, but two source considerations still deserve an explicit decision: whether the baseline fits the organization and whether its threat assumptions fit the environment.

A smaller headcount does not guarantee low impact. Likewise, cybercrime may be the most likely threat while a contractual obligation, sensitive research, strategic role or critical service creates additional requirements.

• Are all potential injuries within the range for which the baseline was designed?
• Is cybercrime a sufficient working threat assumption?
• Do legal, regulatory, contractual or sector requirements call for something more?
• Can the organization operate and verify the controls it selects?

If an answer is uncertain, record the uncertainty and obtain the appropriate risk, legal or sector-specific advice.

From organizational context to a control plan

Once the context is written down, control selection becomes more defensible:

1. List the business services, systems, information and providers in scope.
2. Describe potential confidentiality, integrity and availability consequences.
3. Confirm the primary threat and additional obligations.
4. Name the accountable leader and action owners.
5. Record current controls, available evidence and unknowns.
6. Select and sequence improvements against that context.
7. Review the context when services, providers, threats or obligations change.

This sequence is ByteDefender's application of the publication's structure. It is not a government-mandated assessment process. It also connects naturally to a focused control plan: our related article, Five Cybersecurity Controls Worth Starting With, discusses how smaller organizations can prioritize and verify a manageable first set once their context is understood.

A hypothetical example

Consider a hypothetical 35-person professional-services firm using cloud email, document sharing, an online client portal and an outsourced payroll service. This example is illustrative; it is not a ByteDefender customer or engagement.

A narrow technology inventory might include only employee laptops and the office network. A business-led scope also includes the cloud services and outsourced provider because the firm depends on them to operate and protect client and employee information.

The impact discussion may show that a temporary loss of email is manageable, while unauthorized disclosure or alteration of client information could cause a more serious consequence. Credential theft and financially motivated cybercrime may be likely concerns, while client contracts add assurance requirements.

A senior leader can remain accountable for risk decisions, an internal IT lead can own implementation, and a managed provider can supply operational evidence. Controls can then be recorded with evidence—for example, identity configuration reports or a completed backup-restoration test—rather than assumed from a contract or policy.

The result is not a compliance verdict. It is a clearer basis for choosing which baseline controls to implement first and whether any area requires a more comprehensive approach.

Common ways the process breaks down

• Scoping only owned hardware. Cloud platforms, contracted services and dependencies disappear even though the organization relies on them.
• Assuming small means low impact. Employee count and potential injury answer different questions.
• Starting with control products. A tool is selected before the service, threat or consequence it should address is clear.
• Treating policy as implementation evidence. A written requirement shows intent, not necessarily current operation.
• Outsourcing accountability with the service. A provider may operate controls, but the organization owns the business decision and residual risk.
• Treating the baseline as certification. Applying public guidance does not issue a credential, guarantee an outcome or establish compliance with every obligation.

A useful first working session

A first scoping session does not need to resolve the entire security program. Bring together the accountable leader, the person responsible for IT, and representatives who understand operations, important information and external obligations. Begin with the most important business services and record:

• Supporting systems, data and providers
• Potential confidentiality, integrity and availability consequences
• Primary threats and relevant obligations
• Accountable and operational owners
• Current evidence, unknowns and exclusions

The objective is not to complete every control during the meeting. It is to make the next control decision traceable to documented context.

Where to begin

Before asking which control should come first, establish what the control is expected to protect and what evidence will show that it works.

A concise scope, impact, ownership and evidence record gives leaders a stronger basis for selecting controls, allocating limited capacity and recognizing when a baseline is not enough.