A fractional CISO first 90 days should establish a clear view of business risk, address urgent exposure, align leaders on decisions, test incident readiness, and produce a security roadmap the organization can carry forward. The goal is not to install every tool or rewrite every policy in three months. It is to make the most important risks visible, assign ownership, and start practical work that can be sustained.
Discuss your security priorities
For a company with 50 to 500 employees, the work usually crosses several teams. IT may run the systems, operations may own critical processes, compliance may track obligations, and executives may approve risk and investment decisions. The first 90 days should connect those responsibilities. At the end, leaders should understand what matters most, what is being done, who is accountable, and what needs a decision.
What should the first 90 days accomplish?
A good initial plan is a sequence, not a promise to solve every security issue. By day 90, a fractional CISO should help the organization answer five questions:
Which business processes, systems, and information are most important to protect?
Which weaknesses create urgent exposure, and which can be addressed through planned work?
Who owns risk decisions, remediation, and incident response?
Which regulatory, contractual, or customer requirements shape the security program?
What work should be funded, assigned, and reviewed during the next several quarters?
The answers should be usable. A prioritized risk register, urgent action log, incident response roles, and sequenced roadmap give executives and technical staff a shared reference. These documents should reflect the actual environment, not a generic checklist. They should also distinguish what has been verified from what is still an assumption.
Days 1–30: How do you build risk visibility?
The first month is structured discovery. Recommendations made before understanding the business can waste time or interrupt important work. A CISO first needs to learn how the company operates, what cannot stop, where sensitive information flows, and what obligations influence decisions.
Map business processes and dependencies
Start with conversations with executives, process owners, IT, compliance, and relevant outside providers. Ask which services generate revenue, which activities must continue during disruption, and what would cause serious harm if unavailable or inaccurate. Identify the systems and providers that support those activities. A manufacturer may depend on production and distribution technology; an educational publisher may rely on learning platforms and student-related information. These are prompts for inquiry, not assumptions about any one company.
For each important process, record its business owner, key applications, data involved, major dependencies, and recovery expectations if known. Verify the details with the people who use and maintain the systems. A first inventory does not have to be perfect. It should be accurate enough to show where information is missing and which dependencies deserve closer review. When the company needs executive-level cybersecurity leadership for this work, its fractional CISO services page describes the relevant service path.
Review what is in place, not just what is written
Review current policies, risk assessments, access practices, backups, security monitoring, incident procedures, vendor oversight, and insurance or customer requirements. Meet the IT team and providers to clarify who performs each task and how the company knows it is being done. A written procedure is useful evidence of intent, but it does not prove that the control operates consistently.
Ask practical questions. How are new accounts approved and former staff removed? Who can access administrator accounts? Who receives alerts after hours? When were backups last restored in a test? Which providers can access company systems, and who reviews that access? Record the answers, including gaps and unknowns, without treating an unknown as proof that a control has failed.
Establish an initial risk register
For each significant risk, describe the affected business process or asset, the possible consequence, existing safeguards, an accountable owner, and a recommended next step. Keep the register concise enough for leaders to review. Separate a technical observation from its business effect. For example, rather than writing only “remote access configuration needs review,” explain which business systems are reachable, who is responsible for checking access, and what decision or verification is needed.
Use a consistent basis for prioritization. Consider potential business impact, how exposed the system or process is, whether safeguards are verified, and how quickly the issue could be addressed. Do not imply that a single score predicts an incident. The purpose is to make trade-offs discussable and make sure the most consequential work is not buried in a long list.
Confirm the compliance and contract context
Work with the people responsible for legal, quality, compliance, and customer commitments to determine what requirements actually apply. Depending on the organization, security work may intersect with HIPAA, FERPA, COPPA, FDA QMSR, ISO 13485, FSMA 204, SOC 2, or other obligations. The first month should identify applicable requirements, evidence expectations, and accountable owners. A framework name alone does not establish compliance.
Useful first-month outputs include a stakeholder map, a preliminary asset and dependency view, an initial risk register, and a list of urgent questions for leadership. For broader context about how cybersecurity leadership fits into a mid-market program, see this fractional CISO guide for mid-market leaders.
Days 31–60: How should leaders address urgent gaps?
Once the initial risks are visible, sort the work by urgency, impact, effort, and dependencies. Some gaps call for a prompt control change. Others require a project, budget, or deeper review. The CISO should explain the reason for each priority and confirm that the organization can carry it out safely.
Choose quick actions without overselling them
Validate ownership and processes for privileged and remote access, account lifecycle, backups and recovery, endpoint protection, patching, vendor access, and detection and escalation. The findings should determine the actions. If former employees retain access, for example, clarify the offboarding process, identify affected accounts, remove access as appropriate, and establish a check that can be repeated. If recovery depends on backups whose usability has not been tested, assign a restore test, document its scope and result, and track any dependencies it reveals.
Coordinate changes with system and business owners. A security fix that disrupts production or blocks a necessary workflow can create a different operational problem. Before changing access or systems, identify who needs to approve the change, how it will be tested, and how staff can report an unexpected effect. Record what changed, who owns ongoing operation, and what evidence will confirm the change remains effective.
Separate immediate work from foundational improvements
Use three practical groups. Immediate actions address a serious exposure that can be reduced promptly. Foundational improvements establish repeatable practices, such as a reliable access review or a tested recovery process. Longer-term investments may need design, funding, procurement, or coordination across several departments. This separation helps an organization avoid labeling every backlog item an emergency.
For example, a company may find that access to a critical application is reviewed inconsistently, recovery responsibilities are unclear, and vendor security information is scattered across email. The first action could be to confirm and remove inappropriate access. A foundational task could be to assign a recurring review owner. A longer-term effort might be to standardize how important providers are assessed. The sequence depends on the real exposure, operational constraints, and existing safeguards.
Agree on risk ownership and decision rights
A security leader can assess, advise, coordinate, and track work. Business leaders still need to make decisions about acceptable risk, resources, and operational trade-offs. Establish who can approve an exception, who owns remediation, how unresolved issues reach executives, and which matters require senior leadership or board attention.
Use plain language. For each major item, explain the business process at stake, potential consequences, safeguards already in place, available options, and the decision needed. A CEO, CFO, COO, IT director, or compliance leader can then take part without relying on a technical severity score alone. Record decisions and their owners, including when a risk is accepted for a defined reason and when it must be reviewed again.
Set a useful leadership reporting rhythm
Agree on a short, regular update that covers top risks, overdue actions, decisions needed, incident-readiness work, and meaningful changes in exposure. Keep measures tied to action. Examples include whether a named owner completed an agreed access review, whether a recovery test exposed an unresolved dependency, or whether a decision is blocking remediation.
A dashboard with many numbers but no decision attached can create noise. Start with a manageable set of items and refine it as the organization learns what leaders need to govern. If broader technology and governance questions sit alongside the security work, the executive advisory service offers a relevant point of reference. Security governance should also fit the organization’s wider IT governance framework.
Days 61–90: How do you test readiness and build a roadmap?
The final month should turn discovery and early improvements into repeatable practices. Incident readiness matters because a written plan is not enough if staff do not know how to report a concern or leaders do not know who can make urgent decisions.
Make incident response usable
Confirm how employees report a suspected incident, who receives the report, who can make urgent decisions, and how the organization will contact technical, legal, communications, and business stakeholders. Identify relevant external support arrangements and confirm how to reach them during an event. Keep contact details, escalation routes, and decision authority current.
Run a discussion-based exercise with a plausible scenario. For example, ask what leaders would do if a critical system became unavailable, a provider reported suspicious access, or staff received a credible report that company information had been exposed. Walk through the first hour: Who verifies what is known? Who preserves information for investigation? Who can approve a containment action that could interrupt operations? Who communicates with employees and customers, if needed?
The aim is to reveal unclear authority, missing information, and communication gaps, not to grade individuals. Capture each finding as an action with an owner and due date. Then update the response arrangements and identify any issue that needs a separate technical or legal review. An exercise provides learning; it does not guarantee that every future event will unfold as expected.
Build a sequenced, owned roadmap
Connect each proposed initiative to a risk or business need. Group work into immediate remediation, foundational improvements, and longer-term investment. For each item, identify an accountable owner, dependencies, expected effort or cost range when known, the intended risk reduction, and a way to verify completion. If the estimate is not known, say so and assign the work needed to develop it rather than creating false precision.
A roadmap for one company might include identity and access improvements, a backup recovery exercise, a clearer vendor review process, or stronger monitoring and escalation. Another company may need different priorities because its systems, obligations, and operations differ. The sequence should take account of people’s capacity and operational timing. A short list of owned, feasible initiatives is more useful than a long catalog without resources or decisions.
Review decisions and next-quarter priorities
Before day 90, review the risk register with leadership. Confirm which risks will be mitigated, accepted, transferred, or investigated further, and record who approved each decision. Make visible any action that is complete, in progress, deferred, or waiting for a decision. Agree on next-quarter priorities, owners, and a reporting cadence so the work does not stop when the initial assessment ends.
For organizations in manufacturing, security planning may also need to address the connection between business technology and operational environments. The company’s food and beverage industry IT page and medical device industry IT page describe sector-specific contexts. Those pages are background; actual controls and priorities still need to be based on the organization’s systems and obligations.
What should leaders receive by day 90?
Deliverables should be concise enough to use and detailed enough to support action. The exact format will vary, but leaders should generally expect working materials such as:
Current-state summary: important systems, processes, responsibilities, known dependencies, and significant gaps.
Prioritized risk register: business impact, existing safeguards, treatment options, owners, and decisions still needed.
Urgent action log: agreed changes, accountable owners, due dates, and verification steps.
Incident response arrangements: reporting and escalation paths, decision roles, contact approach, and exercise findings.
Security roadmap: sequenced initiatives, dependencies, ownership, and resources or decisions required.
Leadership reporting approach: a cadence and a focused set of measures that support real decisions.
These materials are not trophies to file away. Their value comes from informed decisions and follow-through. If an important dependency is unknown or an initiative lacks an owner, show that gap plainly. A current picture that admits uncertainty is more useful than a polished document that implies every risk has been resolved.
What can derail the first 90 days?
Starting with tools instead of risk
A purchase may be the right answer, but it should address a defined need. Begin with the risk and desired outcome, then compare possible controls, operating responsibilities, and fit with existing systems. This reduces the chance of acquiring a tool before the company has agreed on the problem it must solve or the people who will run it.
Trying to fix everything at once
A large backlog can overwhelm a small IT team and obscure the most important work. Separate urgent exposure from useful longer-term improvements. Limit the initial commitments to priorities that have owners and realistic next steps. Keep the remaining items visible for later review rather than treating them as forgotten or completed.
Leaving business owners out
Security work can change how staff access systems, handle information, or respond to disruption. Include the people who own those processes. Their input helps identify operational constraints and gives each action an accountable home. Without it, a technically sound control may not fit the work or may never be maintained.
Confusing a plan with implementation
A roadmap describes intended work; it does not prove controls are operating. Track implementation and verify important changes where appropriate. Revisit the risk picture when the business, systems, providers, or obligations change. Make the status of each item clear, and do not label work complete until the agreed evidence is available.
How can a company judge progress at day 90?
Progress is visible when leaders can describe the most important security risks in business terms, know who owns the associated decisions, and see evidence that urgent actions are moving. They should have a usable incident escalation approach, recorded lessons from a discussion exercise, and an agreed roadmap with realistic owners and next steps. The work should also show which questions remain open and who will resolve them.
Frameworks can help teams organize risk and improvement work, but they do not replace understanding the company’s environment. The National Institute of Standards and Technology provides cybersecurity and risk-management resources that organizations can use as reference material. Choose an approach that fits the organization, then translate it into controls, owners, and reviews that can be maintained.
Not every risk will be resolved in three months. A strong first phase produces an honest, prioritized view and a management process that keeps work moving. Leaders considering senior cybersecurity support can review Turning Point Advisory’s fractional CISO service and an overview of the fractional CISO role.
Schedule a conversation about your security program
The first 90 days should leave your company better informed, better prepared to respond, and equipped with a security roadmap that leadership can own.
