Operating guide / Cybersecurity
Put the next security action where it matters.
Growth adds accounts, devices, suppliers and dependencies. A useful security roadmap connects each action to a business service, an accountable owner and evidence that the action works. Start with what could interrupt or expose the business, then keep the safeguards current as the organization changes.
Begin with a business service
Make the priority explainable.
Consider an illustrative business that takes orders through a cloud application. Its continuity may depend on email, administrator access, a payment integration and recoverable records. Buying another security product does not tell the owner which dependency is exposed or whether an order can be processed after recovery.
- Impact identifies what matters
- Name the service, the information it uses and the consequence of losing access or integrity. Include people and suppliers that the service needs.
- Exposure helps decide urgency
- An observed weakness on a critical dependency needs a different response from an untested assumption. Record what is known, what needs investigation and who can act.
- Evidence closes the action
- Assign a specific check to the safeguard: an access review, supported-version record or controlled recovery exercise. A purchase receipt is not operational acceptance.
Six areas to work through
Build protection around how the business operates.
These areas can run in parallel. Suspected active compromise belongs with the authorized incident owner immediately; it should not wait behind routine improvement work.
Ownership and the service inventory
01Priority question: Which services and information would hurt most to lose or expose?
- Business purpose
- Connect technical assets to actual work before making a long shopping list.
- Starting evidence
- Business workflows, application and device lists, information owners and supplier dependencies.
- Practical action
- Map the order service to its accounts, records, integrations and support contacts. Record gaps explicitly and name someone responsible for resolving each one.
- Accountable owner
- Business leaders set priorities; service and information owners explain dependencies and consequences.
- Completion evidence
- An agreed service map with named owners, unresolved questions and a prioritized action record.
- Remaining limit
- An inventory does not establish that the recorded configuration is secure.
- Review trigger
- A new service, acquisition, office or significant data use should prompt a review.
Critical accounts and usable recovery
02Priority question: Who can enter or administer the services we depend on?
- Business purpose
- Reduce avoidable account exposure without leaving the business dependent on one person's phone or memory.
- Starting evidence
- Account owners, authentication settings, privileged roles and documented recovery arrangements.
- Practical action
- Prioritize business-critical accounts. NCSC recommends passkeys where available; protect remaining password access with unique passwords and two-step verification. Review unused access and plan authorized account recovery.
- Accountable owner
- The identity or service owner approves changes, with business ownership retained for critical accounts.
- Completion evidence
- A reviewed access list, confirmed authentication settings and an authorized recovery procedure.
- Remaining limit
- Stronger sign-in does not validate every permission or remove every attack path.
- Review trigger
- Joiners, role changes, leavers and supplier access changes need an access decision.
Supported devices and software
03Priority question: Can the systems used for work receive and apply security updates?
- Business purpose
- Make maintenance a continuing responsibility rather than an occasional emergency.
- Starting evidence
- Device and software versions, support status, update records and exceptions.
- Practical action
- Keep work devices, browsers and apps updated, use automatic updates where appropriate, and plan replacement of unsupported software. Check device access controls and relevant built-in protections.
- Accountable owner
- The technical owner manages the change; an operational owner reviews service-specific constraints.
- Completion evidence
- Current support and update records, checked settings and assigned exceptions.
- Remaining limit
- An update record does not prove that every vulnerability or configuration problem is resolved.
- Review trigger
- A support deadline, new device or failed update needs follow-up.
Recovery that reaches usable work
04Priority question: Can the business use the restored service, not just locate a backup?
- Business purpose
- Turn a claimed recovery capability into a checked operating procedure.
- Starting evidence
- Required records, backup coverage, access arrangements, dependencies and a safe exercise environment.
- Practical action
- Check that important data is included and can be restored. For the order example, the service owner should also verify that the restored records support the intended workflow and identify missing dependencies.
- Accountable owner
- The recovery lead coordinates the exercise; the business service owner decides whether the result is usable.
- Completion evidence
- A dated recovery record covering scope, result, missing items and corrective actions.
- Remaining limit
- A successful exercise covers its tested conditions, not every future incident.
- Review trigger
- Changes to data, applications or recovery access can invalidate earlier evidence.
Detection and a response handoff
05Priority question: Who receives a warning, decides its significance and coordinates action?
- Business purpose
- Give staff and providers a clear route from a suspicious event to an accountable decision.
- Starting evidence
- Available alerts, reporting channels, support arrangements and the incident contact plan.
- Practical action
- Define how a report reaches the responsible team, including when normal email is unavailable. Walk through an illustrative loss of account access and record unclear handoffs.
- Accountable owner
- The designated incident lead coordinates technical and business decisions and obtains specialist help as needed.
- Completion evidence
- A tested contact path, named decision makers and recorded exercise findings.
- Remaining limit
- An alert or exercise is not proof of compromise, nor a substitute for a qualified investigation.
- Review trigger
- Personnel, support hours or provider changes should reopen the contact plan.
Suppliers and changes to the business
06Priority question: Where does our responsibility meet the provider's responsibility?
- Business purpose
- Keep important work from falling between contracts, dashboards and assumptions.
- Starting evidence
- Service scope, administrator access, support contacts, backup responsibilities and exit arrangements.
- Practical action
- Ask who maintains, monitors, restores and communicates for the order application and its integrations. Record the handoff and request relevant evidence without collecting unnecessary sensitive material.
- Accountable owner
- The business service owner accepts the arrangement with the technical and procurement owners.
- Completion evidence
- A responsibility record with evidence requests, open gaps and the next review trigger.
- Remaining limit
- A provider's assurance statement does not establish the configuration or recovery of your own service.
- Review trigger
- New integrations, changed service scope or a provider transition need another review.
A working priority record
Write down what would change the decision.
Use these illustrative entries to shape your own record. They are not a universal ranking, mandatory schedule or complete assessment.
| Observed gap | First action | Dependency to check | Owner | Evidence to request |
|---|---|---|---|---|
| Unknown service ownership | Map the critical workflow | People and integrations | Business service owner | Agreed map and open gaps |
| Unreviewed account access | Review roles and sign-in | Recovery access | Identity owner | Settings and access record |
| Unsupported software | Plan supported replacement | Service compatibility | Technical owner | Support and change evidence |
| Untested recovery | Run a controlled exercise | Required records and services | Recovery lead | Usable result and failures |
| Unclear alert handoff | Exercise the contact path | Unavailable normal channels | Incident lead | Reached owner and decisions |
| Assumed provider coverage | Confirm responsibilities | Contract and configuration | Service owner | Named handoffs and gaps |
Turn the record into a roadmap
Sequence by consequence, exposure and dependencies.
A fixed calendar can hide urgent work or unrealistic prerequisites. Set dates after owners understand the action and the resources needed.
- 01
Choose the critical service
Describe the work, information and dependencies. Record which consequences matter to the business and which facts are still unknown.
- 02
Separate incidents from improvements
Route suspected active compromise through the incident process. For improvement work, record the observed gap and the reason it deserves attention.
- 03
Agree the action and owner
Specify the safeguard, required permissions, dependencies and acceptance evidence. Give unresolved decisions to a named person rather than leaving them in a general backlog.
- 04
Verify the result
Check the actual scope of the change or exercise. Keep incomplete coverage and failed checks visible, with an owner for the next action.
- 05
Reopen when conditions change
Review the record when services, people, suppliers or data change. Use previous evidence as a starting point, not a permanent certificate of safety.
Keep leadership involved
Make the security review a decision meeting.
A useful review explains what changed, what remains exposed and what decision is needed. It should be understandable to the people responsible for the business.
- Report coverage and gaps
- Show which critical services the evidence covers. Do not let a count of completed tickets conceal an unowned dependency.
- Give exceptions an owner
- Record the reason, consequence, interim arrangement and review date for deferred work. The responsible leader needs enough information to accept or reject the exception.
- Protect the evidence
- Keep access lists, configuration details and recovery records available to authorized people. Public marketing claims do not need a copy of sensitive operational material.
- Keep obligations separate
- Use appropriate qualified advice for legal, contractual or sector requirements. A general roadmap or voluntary framework does not establish compliance.
Questions from growing businesses
Ask for a concrete answer and its limits.
Use these questions when reviewing your own roadmap or discussing responsibilities with a provider.
- What should a small business do first?
- Identify the services and accounts it depends on, then examine actual exposure and ownership. Critical account protection, supported systems and checked recovery are practical starting areas. A suspected incident requires its own immediate response.
- Does moving to the cloud remove our security responsibilities?
- No. Confirm responsibility for your accounts, permissions, configuration, information and recovery arrangements. The division varies by service and contract; write it down for the services you actually use.
- Is a backup success message enough?
- It confirms a reported job result. You still need to know what was included and whether authorized staff can restore and use the required information. Record what a controlled recovery exercise did and did not establish.
- Do we need a particular security product?
- Start with the gap and the evidence required to close it. Check existing capabilities, ownership and operating capacity before selecting a product. A tool still needs suitable configuration, maintenance and response responsibility.
- Which framework should guide the work?
- NIST CSF 2.0 offers an organizing structure, including governance, for managing cybersecurity risk. CISA's voluntary CPGs 2.0 prioritize practices for critical infrastructure. Use relevant guidance in context; neither makes this article a complete assessment or a compliance certificate.
Source basis
Sources behind the control model.
- 01
NIST
CSF 2.0 Small Business Quick-Start GuideSP 1300 provides a starting structure for organizations with modest or no cybersecurity program. The article's priority record and order-service example are editorial applications.
- 02
CISA
Cross-Sector Cybersecurity Performance GoalsThe current page describes voluntary CPGs 2.0, their critical-infrastructure scope and alignment with CSF 2.0. The linked full CPG report is not presented here as a completed assessment.
- 03
UK National Cyber Security Centre
Secure your important online accountsReviewed July 2026. Covers passkeys, remaining password protection, two-step verification and unnecessary account access.
- 04
UK National Cyber Security Centre
Protecting your devicesReviewed July 2026. Covers device access, updates, supported software and built-in protections.
- 05
UK National Cyber Security Centre
Backing up your dataReviewed July 2026. Emphasizes important data, protecting backup access and checking restoration. A business service also needs its own acceptance criteria.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD