A security programme should start as a risk-based operating model, not a checklist of tools. The first steps are to assign accountable ownership, define the scope and business risks, assess the current state, turn findings into a prioritised roadmap, and then run that roadmap through owners, artefacts, evidence, reporting, and recurring review.
The practical sequence matters. If you start with tooling before ownership, controls drift. If you start with policy before understanding assets and risk, documentation becomes detached from reality, if you start with compliance before an operating rhythm, readiness becomes a one-off project.
What a security programme is — and what it is not
A security programme is an ongoing way of managing security risk through governance, people, processes, technology, evidence, and improvement. It connects decisions about risk with the controls, owners, procedures, reporting, and reviews needed to keep those decisions current.
Broader than:
- a cyber security policy
- an awareness campaign
- a compliance project
- a set of security tools
- a one-time gap assessment
NIST describes governance activities such as risk tolerances, roles and responsibilities, and policies as part of connecting cybersecurity risk management to organisational decision-making in the Cybersecurity Framework. In practice, that means the programme should answer: who owns risk, what matters most, which controls are expected, how exceptions are approved, how incidents are handled, and how leadership knows whether risk is changing.
The programme is built through sequence and cadence: decide ownership, assess the current state, prioritise work, implement controls, collect evidence, report progress, and repeat.
Start with ownership, scope, and business risk
Before choosing controls, assign a named accountable owner. This does not have to mean hiring a full security team immediately. In a small company, for example, the CTO may be accountable while engineering owns secure development tasks, IT owns device and access controls, operations owns vendor reviews, and leadership approves risk acceptance.
The key, basically, is to separate three responsibilities:
| Responsibility | Practical question |
|---|---|
| Accountability | Who is answerable for the programme and risk decisions? |
| Control ownership | Who implements and operates each control? |
| Reporting | Who tells leadership what is improving, blocked, overdue, or accepted? |
Next, define scope. A first programme should be explicit about what it covers, such as:
- business-critical systems and products
- customer data, employee data, credentials, intellectual property, and other sensitive information
- cloud environments, SaaS platforms, endpoints, networks, and code repositories
- vendors and service providers that handle important systems or data
- customer commitments, contracts, and relevant compliance obligations
- teams and processes that create, access, store, or transmit sensitive data
Then translate risk appetite into operational terms. Avoid abstract statements such as “we have a low risk appetite.” Instead, define what the organisation cannot tolerate, what can be accepted temporarily, and what requires fast remediation.
For example:
- “No shared administrator accounts on production systems.”
- “Critical vulnerabilities on internet-facing systems need owner review and remediation tracking.”
- “A temporary exception to MFA must have an expiry date and accountable approver.”
- “Backups for critical systems must be restorable, not merely configured.”
These statements help teams make decisions when time, budget, and attention are limited.
Assess the current state before building the roadmap
A first assessment turns “we need better security” into a fact-based view of risk and gaps. It does not need to be perfect, or rather complete, but it should be structured enough to support prioritisation.
Assess the current state across areas such as:
- asset and data inventory
- identity, authentication, and privileged access
- employee onboarding, offboarding, and access reviews
- endpoint and device management
- cloud and SaaS configuration
- network exposure and remote access
- backups and recovery
- patching and vulnerability management
- logging and monitoring
- incident response readiness
- vendor and service-provider risk
- security policies, SOPs, and evidence
- customer, contractual, or regulatory obligations
NIST SP 1301 describes using current-state and target-state assessments to understand, tailor, assess, and prioritise cybersecurity outcomes against the organisation’s mission, stakeholder expectations, threat landscape, and requirements (NIST SP 1301). That is the right mindset: the assessment should not just list gaps; it should show what matters for this organisation.
Capture findings in business language — in plain business language. “No central offboarding process” is more useful to leadership than “IAM control deficiency,” because it explains the operational risk: former employees or contractors may retain access longer than intended.
A simple findings log or risk register can include:
| Field | Purpose |
|---|---|
| Finding or risk | What is wrong or uncertain? |
| Affected asset or process | Where does it matter? |
| Business impact | What could happen if it is not addressed? |
| Severity or priority | How important is it relative to other findings? |
| Recommended action | What should change? |
| Owner | Who is responsible for progress? |
| Target date | When will it be reviewed or remediated? |
| Status | Open, in progress, accepted, blocked, complete |
| Evidence needed | What proves the control or action is operating? |
Frameworks can help structure the assessment, but they should not replace business judgement. The NIST CSF provides outcomes for managing and reducing cyber risk, while organisations still need to choose and prioritise actions for their own context (NIST CSF FAQs).
Prioritise the first roadmap when resources are limited
The assessment will usually produce more findings than the organisation can can fix at once. The purpose of the roadmap is to decide what happens first, what waits, what depends on something else, and what leadership accepts as residual risk.
Prioritise findings using a small number of factors:
- Business impact: Which systems, data, or processes would cause the most harm if compromised or unavailable?
- Exposure: Is the issue internet-facing, broadly accessible, privileged, or connected to sensitive data?
- Exploitability: Is it easy to abuse, already known, or dependent on several unlikely conditions?
- Stakeholder pressure: Is it tied to a customer commitment, contract, audit, or regulatory expectation?
- Dependencies: Does this item unlock other controls, such as identity foundations before access reviews?
- Effort and cost: Can a meaningful reduction in risk be achieved quickly, or does it require a longer project?
- Speed of risk reduction: Which actions reduce the most practical risk soonest?
A useful first roadmap separates work into four buckets:
| Bucket | Use it for | Example |
|---|---|---|
| Immediate fixes | Clear, high-risk issues that can be addressed quickly | Enforce MFA for administrators where supported |
| Foundational controls | Capabilities other controls depend on | Asset inventory, identity ownership, backup ownership |
| Planned improvements | Important work that needs sequencing or budget | Centralised logging, vulnerability management maturity |
| Accepted risks | Risks leadership knowingly accepts for a defined reason and period | Temporary exception for a legacy system with compensating controls |
Every roadmap item should have an owner, due date or review date, dependency, evidence requirement, and reporting status. Without those fields, the roadmap becomes a wish list.
Example first security programme roadmap
This 30/60/90-day model is only an example planning structure. It is not a promise that a complete programme can be built in 90 days.
| Phase | Main objective | Practical outputs |
|---|---|---|
| First 30 days | Establish control of the problem | Name accountable owner; define scope; identify critical systems and sensitive data; run initial gap review; create risk register; address obvious high-risk access or exposure issues; agree leadership reporting format |
| Days 31–60 | Convert findings into owned work | Prioritised roadmap; control owners; initial policy set; access management actions; backup and recovery ownership; incident response basics; evidence location; exception and risk-acceptance process |
| Days 61–90 | Start the operating rhythm | First executive scorecard; recurring security review; remediation tracking; access review cycle; vulnerability and patching workflow; incident exercise or tabletop where appropriate; policy/SOP refinements; roadmap refresh |
The sequencing trade-off is deliberate. Urgent identity and access risks may come before polishing policy wording. Backup ownership and incident response basics may matter more than advanced tooling. A small team should not try to implement every control at once; it should make the most important risks visible, owned, and moving.
Put the core artefacts and baseline controls in place
A first programme needs artefacts that help people make and prove decisions. They should reflect how the organisation actually works, not how a policy template imagines it works.
Security programme artefact map
| Flow | Output | What it does |
|---|---|---|
| Assessment | Current-state review | Shows existing systems, controls, gaps, and obligations |
| Risk register | Findings and risks | Converts issues into business impact, priority, owner, and status |
| Prioritised controls | Roadmap | Sequences remediation and improvement work |
| Owners/SOPs | RACI and operating procedures | Defines who performs recurring control activities and how |
| Incident plan | Response process | Sets roles, escalation paths, communications, and recovery coordination |
| Executive scorecard | Leadership report | Shows risk, progress, exceptions, and blockers |
| Review cadence | Operating rhythm | Keeps controls, evidence, and priorities current |
The core artefacts typically include:
- Risk register: the central list of risks, findings, owners, and decisions.
- Control baseline: the controls the organisation expects to operate for its current maturity and risk profile.
- Security roadmap: the prioritised plan for remediation and improvement.
- Policy set: concise rules for areas such as access, acceptable use, data handling, incident reporting, vendors, and secure operations.
- SOPs: step-by-step operating procedures for recurring tasks such as onboarding, offboarding, access reviews, vulnerability triage, and backup checks.
- Incident response plan: a practical guide to roles, escalation, communication, containment, recovery, and post-incident learning.
- Ownership model: a RACI or similar view showing who is accountable, responsible, consulted, and informed.
- Executive scorecard: a small set of metrics that leadership can use to remove blockers and approve risk decisions.
- Evidence repository or workflow: a way to retain proof that controls are operating.
- Review cadence: recurring meetings and checkpoints that keep the programme alive.
Baseline controls should be selected according to context, but early candidates often include the areas below. The CIS Controls provide reference safeguards for asset and data inventory, account and access management, MFA, vulnerability remediation and patching, audit logging, incident response, and service-provider management (CIS Controls Navigator v8).
| Control area | Why it usually appears early |
|---|---|
| MFA where supported | Reduces reliance on passwords alone, especially for privileged and remote access |
| Access management and reviews | Helps ensure users have appropriate access and leavers are removed |
| Asset and data inventory | Shows what systems and data the programme is protecting |
| Backups and recovery testing | Confirms critical systems can be restored, not just backed up |
| Patching and vulnerability management | Creates a process for finding, prioritising, and remediating weaknesses |
| Endpoint protection | Provides basic protection and visibility on user devices and servers |
| Logging and monitoring | Helps detect and investigate events at a level appropriate to maturity |
| Secure configuration | Reduces avoidable exposure from default or inconsistent settings |
| Awareness and reporting behaviours | Helps staff recognise suspicious activity and report incidents quickly |
| Incident response process | Defines what happens when something goes wrong |
| Vendor or service-provider review | Addresses external parties that handle important systems or data |
Do not over-document these controls before they operate. A short, accurate SOP that teams follow is more useful than a long policy that no one can evidence, at least early on.
Build the operating rhythm: reporting, testing, evidence, and improvement
A programme becomes real when it repeats. The recurring rhythm should show whether controls are operating, risks are changing, and owners are following through.
Set a simple cadence, such as:
- a regular security working session for control owners
- a leadership review for material risks, blocked work, and exceptions
- periodic access reviews for important systems
- recurring vulnerability and patch reviews
- backup restore checks for critical systems
- incident response exercises or lessons-learned reviews where appropriate
- policy and SOP reviews when systems, teams, or obligations change
NIST SP 800-37 describes risk management as connecting control selection, implementation, assessment, accountability, and continuous monitoring to organisational risk decisions (NIST SP 800-37 Rev. 2). That is the operating model to aim for: decisions, controls, evidence, monitoring, and adjustment.
Use a small scorecard rather than a large dashboard. Example early metrics include:
| Metric | What it tells leadership |
|---|---|
| Open high-risk findings | Whether material risks are reducing |
| Overdue remediation | Where ownership or capacity is failing |
| Accepted risks nearing expiry | Which decisions need review |
| Access review completion | Whether access governance is operating |
| Backup test status | Whether recovery assumptions have been checked |
| Vulnerability remediation status | Whether known weaknesses are being managed |
| Incident exercises or lessons learned | Whether response capability is improving |
| Evidence freshness | Whether controls can be demonstrated, not just described |
Incident response should also feed improvement. NIST recommends treating incident response as part of cybersecurity risk management and using lessons from incidents and exercises to improve the programme (NIST SP 800-61 Rev. 3). After an incident or exercise, update the risk register, controls, SOPs, training, and roadmap as needed.
Use frameworks and external support without letting them replace judgment
Frameworks are useful references, especially when you need structure, evidence, or customer-facing assurance. They do not decide priorities on their own.
Use them according to context:
- NIST CSF can help describe cybersecurity outcomes and organise risk management conversations.
- CIS Controls can help identify practical safeguard areas for a control baseline.
- ISO/IEC 27001 specifies requirements for an information security management system (ISO/IEC 27001:2022).
- SOC 2 engagements evaluate and report on controls against AICPA trust services criteria (AICPA Trust Services Criteria).
- NIST RMF can inform how control selection, assessment, accountability, and monitoring connect to risk decisions, without being a required commercial process.
External support may be useful depending on the organisation’s risk, skills, and obligations. For example, a consultant or vCISO-style adviser may help with initial assessment and prioritisation; a penetration tester may validate specific technical exposure; an MSSP may support monitoring where internal coverage is limited; an incident response specialist may help prepare for or handle serious events; and a compliance adviser may help align evidence with customer or audit expectations.
Even when specialists are involved, internal ownership should stay clear. External parties can advise, test, monitor, or support, but leadership still needs to decide risk appetite, approve priorities, fund remediation, and hold control owners accountable.
A good first security programme is not the biggest possible control catalogue. It is a repeatable system for turning risk decisions into owned controls, useful artefacts, operating evidence, leadership reporting, and ongoing improvement. Start small enough to actually run, but structured enough to keep improving.