FitzFor a growing 20–50 employee business, reducing technology risk starts with understanding which systems the company cannot operate without—and how quickly those systems must be recovered if something goes wrong.
At Fitz Enterprises, we generally work toward designing recovery capabilities for business-critical applications around a 1–4 hour maximum recovery window, depending on the urgency, criticality, and operational requirements of the business. Some systems may require even faster recovery, while others may justify a longer window following an appropriate business impact and cost analysis.
But that target shouldn’t be selected by the IT provider alone.
The business defines its recovery requirements. Technology must be designed to meet them.
Here is a practical five-step framework business owners can use to identify and reduce technology risk before an outage, cybersecurity incident, or system failure disrupts operations.
1. Identify the Applications Your Business Cannot Operate Without
Before evaluating cybersecurity tools, backup products, or infrastructure, identify your business-critical Line of Business (LOB) applications.
These are the systems that directly support your ability to serve customers, generate revenue, meet obligations, or maintain daily operations.
For a wealth advisory firm, that might include:
- Portfolio management applications
- CRM and client records
- Custodial platforms
- Financial planning software
- Microsoft 365 and email
- Internet and communication systems
For a dental or medical practice, the list may include practice management software, electronic patient records, imaging systems, scheduling, and communications.
The important question isn’t simply which applications employees use most frequently.
It’s:
What happens to the business if this application becomes unavailable tomorrow morning?
Document each critical application, what business function it supports, and who depends on it.
This creates the foundation for every recovery and risk-management decision that follows.
For a broader leadership perspective, see our guide to the technology risks every business owner should discuss in the boardroom.
2. Establish How Long the Business Can Afford to Be Down
Once critical systems are identified, leadership needs to define acceptable downtime.
This is commonly expressed as a Recovery Time Objective (RTO): the target amount of time within which a system or business function should be restored following a disruption.
Consider a 30-employee wealth advisory firm whose portfolio management platform becomes unavailable at 9:00 AM.
Could employees continue operating for:
- 1–4 hours?
- 4–8 hours?
- One full business day?
- Multiple days?
The answer depends on the business—not the technology provider.
At Fitz Enterprises, our general approach is to design recovery capabilities for business-critical applications around a 1–4 hour maximum recovery window, depending on the system’s importance and the business’s operational requirements.
This is a planning benchmark, not a universal guarantee. Applications requiring near-immediate availability may need additional redundancy or high-availability solutions, while less critical systems may justify longer recovery windows based on a documented business impact and cost analysis.
The objective is to establish recovery requirements first, then design and validate the technology needed to meet them.
Leadership should also define a Recovery Point Objective (RPO), which addresses a different question:
How much data could the business afford to lose?
A one-hour recovery target, for example, does not automatically mean one hour of acceptable data loss.
For some applications, losing even an hour of transactions or client information could be unacceptable.
Both requirements need to be established before selecting a recovery solution.
3. Verify That Business Continuity and Backups Actually Work
One of the first things we examine during a technology risk assessment is whether a business continuity plan exists.
If it does, we need to determine whether it reflects the company’s current environment and operational requirements.
If it doesn’t, that becomes a risk that needs to be documented and addressed.
Then we validate two fundamental questions:
A. Does the business actually have backups?
B. Are those backups working, and can the data actually be restored?
These are not interchangeable questions.
A backup dashboard displaying successful jobs does not necessarily prove that a business-critical application can be restored within its required recovery window.
An effective assessment should examine:
- Which systems and data are protected
- How frequently backups occur
- Whether backup failures are monitored
- Whether appropriate backup copies are isolated or otherwise protected
- When restoration was last tested
- Whether recovered data is usable
- How long restoring critical systems would realistically take
- Who is responsible for coordinating recovery
This distinction is important enough that we’ve addressed it separately in Backup Is Not Disaster Recovery.
The objective is to move from assuming recovery is possible to having evidence that recovery can actually be performed.
4. Examine Documentation, Security Policies, and Compliance Requirements
In parallel with continuity and recovery testing, we evaluate documentation and the organization’s existing security policies.
Poor documentation can turn an otherwise manageable outage into a prolonged business disruption.
Consider what happens when the only person who understands a critical configuration is unavailable—or when the information needed to recover a system exists only on a sticky note.
These types of recurring weaknesses are also examples of how reactive IT can create hidden costs throughout a business.
At a minimum, the assessment should identify whether the business maintains appropriate documentation for:
- Critical applications and infrastructure
- Network configurations and dependencies
- Administrative access and credential management
- Technology vendors and support contacts
- Backup and recovery procedures
- Security policies and responsibilities
- Incident escalation and decision-making
Security controls also need to be evaluated against the company’s actual exposure.
That includes reviewing areas such as multi-factor authentication, access management, endpoint protection, and existing security exceptions.
For businesses operating in regulated industries, another question becomes essential:
Do our documented policies, implemented controls, and recovery capabilities align with the requirements applicable to our business?
A wealth advisory firm’s obligations may differ from those of a dental practice or an unregulated professional-services company.
The assessment should account for those differences rather than assuming that one generic security checklist is appropriate for every organization.
5. Turn the Findings Into a Prioritized Risk-Reduction Roadmap
Identifying risks is only useful if the business takes appropriate action.
Once we’ve established critical dependencies, downtime requirements, recovery capabilities, documentation gaps, and security exposure, the findings need to be translated into a business-focused action plan.
At Fitz Enterprises, we use four practical planning horizons:
Critical — 0–30 Days
Issues requiring immediate attention because they create significant operational, cybersecurity, compliance, or recovery exposure.
High — 30–90 Days
Important risks requiring near-term remediation, with sufficient time for appropriate planning and implementation.
Strategic — 3–12 Months
Improvements that should be incorporated into the organization’s annual technology plan and budget.
Long-Term — 12–36 Months
Larger modernization initiatives, infrastructure lifecycle planning, platform changes, and strategic investments.
This prioritization is especially important when accumulated technology debt is creating measurable business costs.
Not every risk requires an expensive technical solution.
Depending on its likelihood, business impact, and cost, an organization may choose to:
- Eliminate the risk
- Reduce its likelihood or potential impact
- Transfer some financial exposure through appropriate insurance or contractual arrangements
- Formally accept the remaining risk
The important distinction is that risk acceptance should be an informed business decision—not the accidental result of an issue being ignored for several years.
This is also where a strategic technology roadmap connects day-to-day IT decisions with broader business objectives. For organizations that don’t have this strategic capability internally, understanding what a fractional CIO actually does can help clarify how technology planning fits into the leadership process.
What Does This Look Like in Practice?
Consider a business that depends heavily on its phone system to receive customer bookings.
A limousine company serving executives traveling between Fairfield County and Manhattan experienced a complete phone outage.
Its new internet provider had already dispatched technicians three separate times, but the phones remained unavailable.
When Fitz Enterprises investigated, we found aging equipment, mismatched infrastructure, and a network that ultimately required rebuilding.
However, the immediate cause of the phone outage was a hidden configuration dependency: the phone system had been configured to trust a specific digital address associated with the previous internet provider.
When the internet connection changed, that dependency prevented the phones from operating.
After identifying the issue, we worked with the carrier to restore service.
The owner’s estimated potential business exposure during the disruption could reach six figures per day. That represented potential revenue at risk—not a verified financial loss.
This illustrates why technology risk assessments must go beyond checking whether individual devices are functioning.
The more important questions are:
What does the business depend on? What could interrupt it? And how quickly could operations be restored?
Technology Risk Should Be Managed Before an Incident Forces the Conversation
Business owners don’t need to understand every technical component in their environment.
They do need confidence that the systems supporting their operations have been identified, their recovery requirements are understood, and appropriate protections are in place.
Start with five questions:
- Which applications can our business not operate without?
- How long can we realistically afford to be without them?
- Have we verified that our backups can actually restore usable data?
- Are our critical systems, recovery procedures, and security responsibilities documented?
- Do we have a prioritized plan for addressing the risks we’ve identified?
Review critical risks quarterly, revisit business recovery requirements as operations change, and maintain a forward-looking 12–36 month technology roadmap.
The objective isn’t to eliminate every possible technology failure. It’s to prevent a technology failure from becoming an unmanaged business crisis.
About Fitz Enterprises
Fitz Enterprises helps growing businesses throughout New England and the Tri-State Area connect technology strategy, cybersecurity, business continuity, risk management, and practical AI adoption to their business objectives.
Our approach begins by understanding the business, identifying its critical dependencies, and designing technology solutions around its operational requirements.
Strategy First. Technology Second.