Tech Advisory

Technology Advice for Small Businesses

powered by Pronto Marketing

Recent Posts

When should a business retain or delete Microsoft 365 documents?

Editor November 9, 2026

Every document a business keeps carries both a cost and a risk. Keep records too briefly and the company may breach a legal requirement or lose evidence it needs. Keep everything forever and storage grows, searches slow down, and old content becomes a liability in a lawsuit or a data breach. Microsoft Purview lets administrators decide by rule what to keep, what to delete, and when. But deciding what to keep is only part of the equation; businesses also need a way to recover data when it is lost.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

A practical guide to document life cycle management in Microsoft 365

Editor November 9, 2026

Many businesses assume that anything stored in Microsoft 365 is both safe and permanent. In reality, content is kept only for as long as the applicable retention settings require, and keeping information available is not the same as ensuring it can be recovered if something goes wrong. Understanding this distinction helps prevent costly surprises, whether a business needs to retrieve an important document or ensure that outdated content is properly removed.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

Microsoft 365 retention explained: Policies, labels, and knowing when to let data go

Editor November 9, 2026

Microsoft 365 will keep or delete content automatically based on retention rules configured by administrators. Retention policies and labels turn legal, regulatory, and business requirements into settings that run quietly in the background. Getting them right means understanding how the rules interact, when deletion is appropriate, and why retention is a different thing from backup.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

How dependencies shape business application availability

Editor November 6, 2026

Cloud application outages can stem from failures in supporting services and infrastructure. A failed sign-in may result from an authentication service outage, an inaccessible website from a DNS or network issue, and an unconfirmed order from a database or payment processing failure. Mapping these dependencies in advance and deciding how the application should respond when they become unavailable can prevent individual service failures from disrupting essential business operations.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

How cloud dependencies affect application availability during an outage

Editor November 6, 2026

When a cloud application becomes unavailable, the cause may lie in a service it depends on rather than in the application itself. Identity providers, DNS, third-party APIs, and background processing all play a role in delivering a working service to users. Identifying which dependencies are essential to business operations helps organizations prepare for service disruptions and keep critical application functions running.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

Why cloud application dependencies matter during an outage

Editor November 6, 2026

A business application can become unavailable even when its core systems are working. A failed identity provider, DNS resolution issue, unresponsive payment API, or backed-up job queue can prevent users from completing essential tasks. These services are dependencies that applications rely on to function. Understanding which dependencies are critical to business operations is essential to maintaining availability when individual services fail.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

Beyond the password handoff: Preserving institutional knowledge before an IT departure

Editor November 4, 2026

Every business has at least one person who knows why things are configured the way they are. Until that knowledge is written down, it belongs to the individual rather than the company. Keeping a simple log of technology decisions turns individual knowledge into a shared reference material and makes leadership transitions far smoother.

What access handoffs leave out

NIST SP 800-53 addresses employee departures through personnel termination control PS-4. It calls for disabling system access, conducting exit interviews, retrieving security-related property, and ensuring continued access to the information and systems the departing employee managed.
These steps are important, but they protect access rather than preserve institutional knowledge. A business can retain every credential and still not know why an exception was granted, which integration is fragile, or when a critical domain needs renewal.

What an IT decision log contains

An IT decision log is a running record of significant technology decisions, with one entry for each major choice. Each entry should be brief, usually about half a page, and cover a few key points: what was decided and when, who is responsible, which alternatives were considered, why the option was chosen, what risks were accepted, and when the decision should be reviewed. Examples include choosing a backup product, granting a permanent firewall exception, or standardizing on an email platform.
A sample entry might look like this:

  • Decision: Moved off-site backups to a second cloud provider
  • Owner: IT manager, with the operations lead as backup
  • Alternatives considered: Tape rotation and replication with the same provider
  • Reason for decision: A single-provider outage could affect both primary and backup copies
  • Dependencies: A service account in the identity provider and a nightly backup job at 2:00 a.m.
  • Review date: 12 months

Store the log in a shared, access-controlled location with regular backups. Keeping it in a personal notebook or on a single employee’s drive defeats its purpose.

Document dependencies alongside decisions

Decisions rarely stand alone, so each entry should note what depends on it. Record which systems rely on which, where service accounts and API keys are used, who holds administrator access and where recovery codes are stored, and which vendors, licenses, and domains renew on what dates. A separate one-page dependency map for the five or six most critical systems is often more useful in a crisis than a long policy document.

Make the habit routine, not a cleanup project

Waiting until an employee gives notice to document their decisions leaves little time to capture everything accurately. To avoid this, add an entry whenever a change is approved and review the log quarterly. Make documentation part of existing routines by including a log update in the change approval process and adding a step to the offboarding checklist to confirm that the departing employee’s decisions and dependencies have been recorded.

How a log simplifies leadership transitions

New IT managers, incoming business owners, and replacement service providers often face the same challenge: inheriting a working IT environment without knowing its history. A decision log helps shorten the learning curve and prevents past decisions from being reversed without understanding the reasons behind them. It also makes it easier to respond to cyber insurance questionnaires, audits, and vendor reviews because the relevant decisions and reasoning are already documented.

A practical way to begin

If no log exists, start small. Identify the most critical systems, then schedule a 30-minute conversation with the person who knows each system best. Use these conversations to document key decisions and dependencies. Prioritize employees who may leave soon and systems with little existing documentation. A simple shared template and monthly reminder can help keep the process going.
If you’re concerned about what your business would lose if a key IT person left tomorrow, our team can help. We’ll guide you in building a decision log, mapping your critical dependencies, and putting a practical knowledge transfer process in place. Reach out to get started.

IT decision logs: The simple habit that protects your business when key people move on

Editor November 4, 2026

Offboarding checklists cover accounts, devices, and badges but rarely capture the reasoning behind IT decisions. An IT decision log fills that gap by recording key decisions, why they were made, and which systems they affect. This helps businesses retain critical knowledge when employees leave.

What access handoffs leave out

NIST SP 800-53 addresses employee departures through personnel termination control PS-4. It calls for disabling system access, conducting exit interviews, retrieving security-related property, and ensuring continued access to the information and systems the departing employee managed.
These steps are important, but they protect access rather than preserve institutional knowledge. A business can retain every credential and still not know why an exception was granted, which integration is fragile, or when a critical domain needs renewal.

What an IT decision log contains

An IT decision log is a running record of significant technology decisions, with one entry for each major choice. Each entry should be brief, usually about half a page, and cover a few key points: what was decided and when, who is responsible, which alternatives were considered, why the option was chosen, what risks were accepted, and when the decision should be reviewed. Examples include choosing a backup product, granting a permanent firewall exception, or standardizing on an email platform.
A sample entry might look like this:

  • Decision: Moved off-site backups to a second cloud provider
  • Owner: IT manager, with the operations lead as backup
  • Alternatives considered: Tape rotation and replication with the same provider
  • Reason for decision: A single-provider outage could affect both primary and backup copies
  • Dependencies: A service account in the identity provider and a nightly backup job at 2:00 a.m.
  • Review date: 12 months

Store the log in a shared, access-controlled location with regular backups. Keeping it in a personal notebook or on a single employee’s drive defeats its purpose.

Document dependencies alongside decisions

Decisions rarely stand alone, so each entry should note what depends on it. Record which systems rely on which, where service accounts and API keys are used, who holds administrator access and where recovery codes are stored, and which vendors, licenses, and domains renew on what dates. A separate one-page dependency map for the five or six most critical systems is often more useful in a crisis than a long policy document.

Make the habit routine, not a cleanup project

Waiting until an employee gives notice to document their decisions leaves little time to capture everything accurately. To avoid this, add an entry whenever a change is approved and review the log quarterly. Make documentation part of existing routines by including a log update in the change approval process and adding a step to the offboarding checklist to confirm that the departing employee’s decisions and dependencies have been recorded.

How a log simplifies leadership transitions

New IT managers, incoming business owners, and replacement service providers often face the same challenge: inheriting a working IT environment without knowing its history. A decision log helps shorten the learning curve and prevents past decisions from being reversed without understanding the reasons behind them. It also makes it easier to respond to cyber insurance questionnaires, audits, and vendor reviews because the relevant decisions and reasoning are already documented.

A practical way to begin

If no log exists, start small. Identify the most critical systems, then schedule a 30-minute conversation with the person who knows each system best. Use these conversations to document key decisions and dependencies. Prioritize employees who may leave soon and systems with little existing documentation. A simple shared template and monthly reminder can help keep the process going.
If you’re concerned about what your business would lose if a key IT person left tomorrow, our team can help. We’ll guide you in building a decision log, mapping your critical dependencies, and putting a practical knowledge transfer process in place. Reach out to get started.

How to document technology decisions before an employee leaves

Editor November 4, 2026

When a long-tenured employee leaves, the most valuable knowledge they take with them is rarely a list of passwords. Rather, it’s the reasoning behind IT decisions: why a firewall rule exists, why backups run at two in the morning, or why one vendor was chosen over another. Access can be transferred quickly, but that knowledge is harder to replace. An IT decision log preserves institutional knowledge by recording what was decided, why, and what depends on it.

What access handoffs leave out

NIST SP 800-53 addresses employee departures through personnel termination control PS-4. It calls for disabling system access, conducting exit interviews, retrieving security-related property, and ensuring continued access to the information and systems the departing employee managed.
These steps are important, but they protect access rather than preserve institutional knowledge. A business can retain every credential and still not know why an exception was granted, which integration is fragile, or when a critical domain needs renewal.

What an IT decision log contains

An IT decision log is a running record of significant technology decisions, with one entry for each major choice. Each entry should be brief, usually about half a page, and cover a few key points: what was decided and when, who is responsible, which alternatives were considered, why the option was chosen, what risks were accepted, and when the decision should be reviewed. Examples include choosing a backup product, granting a permanent firewall exception, or standardizing on an email platform.
A sample entry might look like this:

  • Decision: Moved off-site backups to a second cloud provider
  • Owner: IT manager, with the operations lead as backup
  • Alternatives considered: Tape rotation and replication with the same provider
  • Reason for decision: A single-provider outage could affect both primary and backup copies
  • Dependencies: A service account in the identity provider and a nightly backup job at 2:00 a.m.
  • Review date: 12 months

Store the log in a shared, access-controlled location with regular backups. Keeping it in a personal notebook or on a single employee’s drive defeats its purpose.

Document dependencies alongside decisions

Decisions rarely stand alone, so each entry should note what depends on it. Record which systems rely on which, where service accounts and API keys are used, who holds administrator access and where recovery codes are stored, and which vendors, licenses, and domains renew on what dates. A separate one-page dependency map for the five or six most critical systems is often more useful in a crisis than a long policy document.

Make the habit routine, not a cleanup project

Waiting until an employee gives notice to document their decisions leaves little time to capture everything accurately. To avoid this, add an entry whenever a change is approved and review the log quarterly. Make documentation part of existing routines by including a log update in the change approval process and adding a step to the offboarding checklist to confirm that the departing employee’s decisions and dependencies have been recorded.

How a log simplifies leadership transitions

New IT managers, incoming business owners, and replacement service providers often face the same challenge: inheriting a working IT environment without knowing its history. A decision log helps shorten the learning curve and prevents past decisions from being reversed without understanding the reasons behind them. It also makes it easier to respond to cyber insurance questionnaires, audits, and vendor reviews because the relevant decisions and reasoning are already documented.

A practical way to begin

If no log exists, start small. Identify the most critical systems, then schedule a 30-minute conversation with the person who knows each system best. Use these conversations to document key decisions and dependencies. Prioritize employees who may leave soon and systems with little existing documentation. A simple shared template and monthly reminder can help keep the process going.
If you’re concerned about what your business would lose if a key IT person left tomorrow, our team can help. We’ll guide you in building a decision log, mapping your critical dependencies, and putting a practical knowledge transfer process in place. Reach out to get started.

Stress-test your incident response plan with a tabletop exercise and no downtime

Editor November 2, 2026

For small and medium-sized businesses (SMBs), knowing who makes key decisions during a cyberattack is essential. A cybersecurity tabletop exercise helps teams identify responsibilities, test response procedures, and clarify escalation paths before an actual breach occurs. Through guided discussions rather than live system testing, businesses can improve their incident readiness without disrupting daily operations.

Why a discussion-based test fits a working business

NIST SP 800-53 Rev. 5 includes control IR-3, which asks organizations to test the effectiveness of their incident response capabilities at a frequency they define. The control identifies checklists, walk-throughs, tabletop exercises, and simulations as acceptable testing methods. NIST’s exercise guidance, SP 800-84, also classifies tabletops as discussion-based exercises. This makes them appealing to businesses: they can test their response plans without shutting down operations, rerouting systems, or simulating incidents on production systems.
Few SMBs are directly subject to NIST SP 800-53, but it remains a useful benchmark. PCI DSS, for example, also requires organizations to test their incident response plans at least annually.

Choose scenarios that match your real exposure

Generic scenarios tend to produce generic answers, so choose two or three situations that reflect the business’s actual risks. These might include ransomware affecting the main file server, a hijacked email account sending a fraudulent payment request, a lost laptop containing customer records, or a breach at a SaaS vendor that stores business data.

Write each scenario as a short narrative, then prepare three or four scenario updates, known as injects. These are new details the facilitator introduces at specific intervals. For example, an inject might reveal that backups are also encrypted or that a customer has reported receiving suspicious emails. Introducing information in stages encourages participants to make decisions with incomplete information, just as they would during a real incident.

Assign decision-making responsibilities beforehand

Confusion over who decides is among the most common failures in a live incident, so the exercise should expose it. List the decisions most likely to arise: isolating affected systems, contacting the cyber insurance carrier, engaging legal counsel, notifying customers or regulators, deciding whether to pay a ransom, and approving public statements. Name an owner and a backup for each.

Invite the people who would actually hold those roles. That usually means IT or the managed services provider, an executive sponsor, legal or compliance, HR, and whoever handles communications. Assign some to take notes, recording decisions, assumptions, and open questions.

Test escalation, not just technical response

Technical steps tend to get the attention while escalation paths do not. Walk through who is contacted first, when the executive team joins, and how each person is reached. Ask what happens if email and the phone system are down, since many plans assume both are available. Confirm that contact details are current, including after-hours numbers for the IT provider and the insurer. Note how long each handoff takes in discussion, because a delay that seems minor around a table becomes serious in a live event.

Keep the session short and low-risk

Schedule the exercise at a quiet time, cap it at 90 to 120 minutes, and keep essential coverage in place so customer-facing work continues. A neutral facilitator, either an outside party or someone who does not own the plan, keeps the pace moving and the tone blame-free. The aim is to find weaknesses in the plan rather than in the people reading it.

Measure readiness with criteria set in advance

Define success before the session starts. Useful measures include whether every decision had a named owner, how long the group took to agree on a first containment step, whether contact lists proved accurate, and how many steps turned out to be unclear, outdated, or impossible to carry out. Record each gap with an owner and a due date in a short after-action report, ideally within a week.
Two weaknesses recur: findings that never make it back into the plan, and key people who were left out of the room. Updating the plan promptly and retesting the revised sections turns a single exercise into steady improvement. NIST also encourages coordinating incident response testing with related plans, such as contingency planning, so the next session can pick up where this one’s backups failed.

Want a tabletop exercise built around your own systems, staff, and risks? Our team can facilitate the session, document the findings, and help turn them into a stronger response plan. Reach out whenever you are ready to schedule one.

Website Management for Small Business Owners

Full-service, pay-as-you-go WordPress websites, from design and content to SEO and Google Ads management for an affordable monthly price.

Learn more about our website management services for small businesses.

Search
Archives