A 90-day cybersecurity action plan for a growing business

Use a framework, then make the plan specific

NIST’s Cybersecurity Framework 2.0 organises cybersecurity outcomes under six functions: Govern, Identify, Protect, Detect, Respond and Recover. Its small-business guide helps organisations with limited existing programmes start managing cyber risk. The framework is voluntary guidance, not a guarantee of security or a universal certification checklist. [1]

The 90-day sequence below is a suggested implementation plan for a growing business. It is not a deadline prescribed by NIST. Adjust the work to your risk, staffing and existing controls. If an active incident or exposed critical system is discovered, immediate containment and specialist investigation take priority over the timetable.

Days 1–15: establish ownership and a credible inventory

Appoint a business sponsor who can approve priorities and an operational owner who coordinates delivery. List the services that would stop revenue, customer support or payroll if they failed. Then identify the accounts, devices, applications and suppliers supporting each service. Include cloud subscriptions purchased outside the IT team and access granted to contractors.

For each critical service, record an owner, administrator, support contact, data classification and recovery expectation. Review departure processes: when a person leaves, which accounts are disabled, who owns their shared files, and which service credentials might have been tied to their identity? The first deliverable should be a usable inventory with clearly marked unknowns, rather than an attractive but incomplete dashboard.

Days 16–30: reduce identity exposure

CISA recommends that businesses aim for phishing-resistant multifactor authentication. This is stronger than simply counting how many users have any second factor: different methods provide different protection. [2] Prioritise email, identity administration, remote access and other high-impact systems when planning deployment.

Test enrolment and recovery with a small group before a wider rollout. Include users who lose a device, work remotely or cannot use a personal phone. Document emergency access, restrict who can use it and monitor its use. Separate administrative accounts from ordinary daily activity, remove unused privileges and make access reviews part of the service owner’s responsibilities.

Avoid measuring success solely by enrolment numbers. Ask whether privileged accounts are covered, whether bypass routes remain, and whether support staff can safely recover access without trusting an unverified caller.

Days 31–45: patch with context and reduce unnecessary access

Create a repeatable process for identifying updates, deciding urgency, deploying changes and verifying the result. Prioritise systems based on exposure and business impact; a device reachable from the internet may need a different response from an isolated laboratory machine. Give exceptions an owner, compensating controls and an expiry date.

Review remote access methods, unsupported software and unnecessary services. Work with application owners before removing access that production systems depend on. If a critical application cannot be patched immediately, document why, narrow access where possible, and agree an upgrade or replacement path. Managed IT support can help sustain this work after the initial project finishes.

Days 46–60: demonstrate recovery

CISA’s StopRansomware guidance recommends maintaining offline encrypted backups and regularly testing their availability and integrity. It also discusses immutable storage options and the need to understand their configuration. [3] Select a recovery design that fits your environment rather than assuming a product label proves resilience.

Run a restore exercise for one critical service. Use a controlled environment and record what was restored, the recovery point, time taken, missing dependencies and whether users could complete a real task. Include configurations, identity dependencies and access to recovery documentation. If the backup administrator’s normal account is unavailable, the recovery team still needs a secure way to operate.

Days 61–75: practise an incident

Hold a short tabletop exercise around a plausible event: a compromised email account sending payment-change requests. Ask who receives the report, who can disable access, how evidence is preserved, and who speaks to customers or suppliers. Confirm contacts through a channel the incident has not compromised.

Do not make the exercise depend on perfect technical knowledge. The purpose is to find unclear authority and missing information. Record the first five decisions the team would need to make and identify which can be made immediately. Legal, contractual and regulatory notification duties vary, so include the appropriate advisers in the response plan rather than inventing one universal deadline.

Days 76–90: review evidence and fund the next cycle

Present a short scorecard: critical services with owners, privileged accounts protected by the chosen authentication standard, overdue high-priority remediation, completed restores and unresolved exercise findings. Include the denominator and exclusions for every percentage. A result of 95 percent is hard to assess without knowing which 5 percent remains.

Agree the next quarter’s actions and the operational cadence for maintaining what you built. The result should be a living programme with documented decisions, not a one-off checklist. Evo’s Cybersecurity team can assess exposure and design controls, while Managed IT Services can support monitoring, patching and daily administration. Start with the business service whose interruption would hurt most.

Frequently asked questions