How do organisations get started with a security programme?

Start with scope, ownership, and a realistic first cut

A security programme starts best when it is framed as a business risk programme, not a tool rollout. The first job is to define what matters most: critical assets, key identities, sensitive data, and the threats most likely to affect them. That gives you a scope that is defensible, measurable, and small enough to execute.

Ownership matters as much as scope. If no one owns the programme direction, priorities drift into disconnected projects and one-off fixes. A clear sponsor, a decision path for exceptions, and a short list of success measures make it easier to keep the programme tied to risk rather than vendor features.

For many teams, the right starting point is to inventory what exists, identify which accounts and systems have the broadest access, and then close the most obvious gaps first. That is where CISO Guide: First 90 Days is useful as a practical planning model, because the same early discipline applies whether the role is a new CISO, a security lead, or a small team building from scratch.

Why the first controls should be simple and measurable

The opening control set should focus on visibility and control, not sophistication. Asset inventory tells you what must be protected, identity hardening reduces easy compromise paths, logging gives you evidence, vulnerability management reduces known exposure, and incident response ensures the programme can act when prevention fails. These controls are basic because they create the operating picture the rest of the programme depends on.

It is usually a mistake to begin with advanced tooling before these basics are stable. If you cannot identify your assets, verify who can access them, or show that alerts are retained and reviewed, then later investments will be hard to measure and harder to defend. A strong first phase should produce visible evidence of control, not just policy statements.

For control selection and implementation detail, the most direct external reference is ISO/IEC 27002:2022 Information Security Controls, because it is built for turning programme intent into practical safeguards across organisational, people, physical, and technological domains.

That baseline should also include credential and access hygiene, because weak accounts, stale secrets, and excessive privilege are common early failure points. Even in a broad security programme, the identities that can administer systems, access data, or approve changes often determine how quickly a small weakness becomes a major incident.

Build the programme around risk, then expand by maturity

The strongest early programmes use risk to decide sequencing. High-impact assets, exposed internet-facing systems, and privileged access paths deserve attention before lower-value or low-exposure areas. This keeps the roadmap aligned to consequence, which is what executives usually need in order to keep funding and attention steady.

Once the basics are in place, expand by maturity rather than by topic list. For example, move from inventory to ownership, from logging to detection use cases, from patching to vulnerability prioritisation, and from incident response plans to rehearsed exercises. That sequence helps prevent a programme from becoming a collection of controls that exist on paper but do not change outcomes.

Programme leaders should also define what good looks like early. If you cannot say how many critical assets are inventoried, how quickly high-severity vulnerabilities are addressed, or whether privileged access is reviewed on schedule, then you will struggle to prove improvement. Measurable priorities are what turn security from a recurring cost into an управляемable operational discipline.

Practitioner Guidance

What to prioritise: Start with the smallest set of controls that creates operational visibility and reduces the most consequential exposure. In practice, that usually means asset inventory, privileged access review, logging coverage, and a remediation path for the highest-risk vulnerabilities.

What to verify: Confirm that every critical system has an owner, every privileged account has an accountable purpose, and every control you claim to have is producing evidence that can be reviewed. If you cannot show it, the programme is not yet real.

Decision rule: If a proposed initiative does not reduce risk, improve visibility, or support response, defer it until the programme has established a stable baseline. Early momentum comes from removing exposure, not from adding complexity.

Practitioner takeaway: The fastest way to get started is to make the programme narrowly measurable, risk-led, and operationally owned, then widen scope only after the first controls are demonstrably working.

Related resources from NHI Mgmt Group

• How do organisations get started with Privacy Programme Management?
• How should an organisation get started with a security champion programme?
• How do organisations get started with OT Security Operations Centre?
• How do organisations get started with OT Security Assessment?