Executive and vCISO Insights
The 90-Day Executive Cybersecurity Operating Plan: Govern, Prioritize, Test, and Report
A useful first 90 days should not try to rebuild every security control. It should establish who owns cyber risk, identify the business operations that matter most, reduce the most credible exposure, prove that response and recovery can work, and give executives a reliable way to make decisions.
This plan uses the six functions of the NIST Cybersecurity Framework 2.0—Govern, Identify, Protect, Detect, Respond, and Recover—as an operating structure. It is not a certification checklist. The outcome is a prioritized, evidence-backed program that can continue after day 90.
Executive outcomes by day 90
Leadership should be able to answer:
- Who is accountable for cybersecurity decisions?
- Which business services and information are most critical?
- What are the top current risk scenarios?
- Which internet, identity, remote-access, vendor, and privileged paths require urgent work?
- Can the organization detect and contain an incident?
- Can it restore minimum viable operations from protected recovery capability?
- Which risks were reduced, which remain, and who accepted them?
- What funding and operating decisions are needed next?
The framework behind the plan
NIST says the Cybersecurity Framework 2.0 can be used by organizations of any size, sector, or maturity to understand, assess, prioritize, and communicate cybersecurity outcomes. The 2.0 release added Govern as a core function, making leadership, policy, roles, risk strategy, oversight, and supply-chain considerations explicit.
CISA’s Cross-Sector Cybersecurity Performance Goals provide a complementary set of high-impact practices. NIST SP 800-61 Rev. 3 connects incident response to CSF 2.0 rather than treating response as an isolated technical procedure.
Days 1–30: establish ownership and reality
1. Name accountable owners
Define:
- executive sponsor;
- security leader;
- IT and cloud control owners;
- legal and privacy roles;
- business-service owners;
- incident commander and alternates;
- communications authority;
- risk-acceptance authority; and
- board or governing-body reporting route.
Use a decision-rights matrix, not a list of names. It should state who decides containment, operational shutdown, customer communication, regulatory notification, insurer engagement, payment holds, restoration, and residual-risk acceptance.
2. Identify critical business services
Start with services, not devices. Examples may include:
- patient care or appointment operations;
- order-to-cash;
- payroll;
- payment and wire approval;
- customer support;
- manufacturing and distribution;
- legal case management;
- tax preparation;
- property transactions;
- email and collaboration;
- identity and access;
- backup and recovery; and
- regulated reporting.
For each service, identify required people, locations, identities, applications, data, infrastructure, vendors, manual workarounds, maximum tolerable downtime, and recovery sequence.
OC Security Audit’s Business Impact Analysis and Cyber Risk Prioritization guide provides a deeper service-based approach.
3. Build the priority risk register
Write risk scenarios in business terms:
If a threat exploits a weakness in a defined environment, then a business service may be disrupted or information affected, causing specified operational, financial, legal, or safety consequences.
Good examples include:
- cloud administrator account takeover affecting email and files;
- business email compromise changing payment instructions;
- exploited internet-facing appliance enabling internal access;
- ransomware or destructive activity interrupting operations;
- failed backup recovery prolonging downtime;
- vendor compromise affecting shared data or access; and
- unsupported systems creating unremediable exposure.
Rank scenarios with likelihood evidence, business impact, current controls, control confidence, and recovery capability. Avoid a long register of generic labels.
4. Establish a minimum evidence baseline
Collect current, authoritative evidence:
- identity and privileged-role exports;
- authentication and Conditional Access configuration;
- external attack-surface inventory;
- vulnerability and patch status;
- endpoint and server coverage;
- firewall and remote-access configuration;
- cloud security configuration;
- backup and restoration results;
- logging sources and retention;
- incident plans and exercises;
- security policies and exceptions;
- vendor access and critical contracts; and
- cyber-insurance requirements.
Record source, collection date, owner, and limitations.
Day-30 executive deliverable
A concise package:
- governance and decision rights;
- critical-services map;
- top 10 risk scenarios;
- immediate containment actions;
- evidence gaps;
- 60-day remediation priorities; and
- decisions or funding required.
Days 31–60: reduce priority exposure
1. Harden identity first
Review:
- privileged accounts and separate administrative identities;
- phishing-resistant authentication for high-risk access;
- legacy authentication;
- Conditional Access coverage;
- emergency-access accounts;
- inactive and orphaned accounts;
- mailbox forwarding and application consent;
- service principals and secrets;
- password-reset and recovery;
- privileged access to backup and security tools; and
- sign-in and audit-log monitoring.
Identity controls influence cloud, email, applications, endpoints, and remote work, so weaknesses can create broad paths.
2. Address confirmed and exposed vulnerabilities
Prioritize:
- CISA Known Exploited Vulnerabilities;
- internet-reachable assets;
- identity and remote-access systems;
- unsupported or end-of-life platforms;
- vulnerabilities on critical services;
- weaknesses with credible exploitation evidence; and
- findings that cannot be detected because logs are absent.
Require remediation verification. A ticket closed after “patch deployed” is weaker than a ticket with build evidence, rescan results, functional test, and review for possible pre-patch exploitation.
3. Protect recovery capability
Confirm:
- backup scope;
- independent administrative control;
- immutable or offline protection where appropriate;
- encryption and key access;
- restoration of applications, identity, configurations, and data;
- recovery dependencies;
- alternate communications;
- minimum viable operations; and
- recent test evidence.
If the organization has never restored a representative critical service, backup confidence is unproven.
4. Improve detection coverage
Map priority scenarios to evidence:
- identity sign-ins and administrative changes;
- endpoint activity;
- email and collaboration events;
- firewall, VPN, and remote-access activity;
- cloud control-plane and workload logs;
- critical application and database events;
- backup administration;
- vendor access; and
- high-risk business transactions.
Define who reviews alerts, how quickly, how escalation works, and what happens outside business hours.
5. Control vendors and business processes
For critical providers:
- identify services, data, and access;
- confirm responsible owner;
- review authentication and privileged access;
- verify incident notification and support contacts;
- understand continuity and exit options;
- collect relevant assurance; and
- track unresolved findings.
For payment and high-impact workflows, add out-of-band verification, dual approval, and change holds where appropriate.
Day-60 executive deliverable
- risk reductions completed and evidence;
- remaining exposed critical paths;
- recovery readiness;
- detection coverage and gaps;
- vendor and business-process risks;
- exceptions with owners and deadlines; and
- the exercise plan for days 61–90.
Days 61–90: test, measure, and institutionalize
1. Run an incident exercise
Use a scenario tied to a real critical service. Include technical, executive, legal, finance, operations, communications, vendor, and insurance decisions.
Test:
- detection and declaration;
- incident command;
- evidence preservation;
- containment authority;
- minimum viable operations;
- customer and workforce communication;
- regulatory and contractual analysis;
- restoration priorities;
- decision logging; and
- return-to-operation criteria.
An exercise should produce assigned corrective actions, not only attendance.
2. Test restoration
Restore representative systems and data in the required sequence. Validate:
- access and identity;
- application function;
- data integrity;
- security monitoring;
- integrations;
- business-owner acceptance;
- recovery time; and
- reconciliation of work performed during downtime.
3. Validate priority controls
Sample and test:
- privileged access;
- MFA and Conditional Access;
- account termination;
- vulnerability closure;
- endpoint coverage;
- logging and alert response;
- backup protection;
- firewall rules;
- vendor access; and
- payment-change verification.
Design evidence so a reviewer can trace the control objective, population, sample, test, result, exception, and remediation.
4. Approve a 12-month roadmap
Sequence work by:
- risk reduction;
- business dependency;
- regulatory or contractual deadline;
- technical prerequisite;
- resource and change capacity;
- lifecycle replacement; and
- validation requirement.
Each initiative needs an owner, outcome, milestone, cost range, dependency, and measure of completion.
Day-90 executive and board report
Keep the report decision-oriented:
- critical services and risk posture;
- top scenarios and change since day 1;
- material control improvements;
- exercise and recovery results;
- open high-risk exceptions;
- vendor and concentration risk;
- incidents and lessons, if any;
- 12-month roadmap;
- funding and decisions; and
- trend metrics with source and limitation.
Metrics worth using
| Metric | Why it matters |
|---|---|
| Critical services with tested recovery | Connects technology to operational resilience |
| Privileged access protected by approved strong authentication | Measures a high-impact control |
| Internet-facing KEV assets past target | Exposes urgent residual risk |
| High-risk findings with validated closure | Measures evidence, not ticket activity |
| Critical log sources with active review | Measures visibility |
| Open risk exceptions by owner and age | Makes accepted risk accountable |
| Critical vendors with current security review | Shows dependency oversight |
| Exercise actions closed on time | Measures learning |
Avoid vanity metrics such as the raw number of blocked events, alerts, policies, or tools unless they support a decision.
Common first-90-day failures
- Buying technology before identifying the service and risk it must address.
- Producing an inventory without owners or business dependencies.
- Treating compliance status as a substitute for operational testing.
- Reporting technical volume instead of risk and outcomes.
- Accepting risk without a named owner and expiration.
- Running a tabletop without closing actions.
- Assuming backups work because jobs are green.
- Letting audit, implementation, and validation roles blur.
- Trying to fix every issue at once.
Turn 90 days into a durable program
OC Security Audit provides cybersecurity governance, risk, assessment, and vCISO guidance. Review the broader Cybersecurity Program Development and Roadmap approach or contact OC Security Audit to discuss an executive-focused review.
Prepared and reviewed by Ali Hassani, CISO.
Keep decisions traceable with an executive cyber-risk decision register, define oversight for new technology with the AI security governance guide, and test response ownership with the first-alert incident-response operating sequence.
Sources
- NIST Cybersecurity Framework
- NIST Cybersecurity Framework 2.0 publication
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
- CISA Cross-Sector Cybersecurity Performance Goals
- CISA Known Exploited Vulnerabilities Catalog
Last fact-checked July 2026. This operating plan should be adapted to the organization’s legal, regulatory, contractual, safety, and operational requirements.