# 6.3 Validate Restored Systems and Business Operations

# Goals

A system is not recovered just because it turns back on.

After restoration, the company must confirm that the system works, the data is usable, access is correct, security controls are active, backups are running, and the related business process can operate safely.

Recovery validation has two sides:

• Technical validation confirms that the restored system is secure, stable, monitored, and protected.

• Business validation confirms that employees can actually perform the required work.

Both are needed. A server may be online while the finance team still cannot issue invoices. A file share may be restored while permissions are wrong. A website may load while forms, payments, or customer records are broken. A SaaS tool may be accessible while public sharing or admin roles remain unsafe.

The goal is to confirm that restored systems can be trusted and used.

# Step 1: Confirm the System Restored Correctly

Check that the restored system, application, device, website, database, SaaS platform, or file location is available and functioning.

Confirm that required services start, users can reach the system, core functions load, integrations connect, and no obvious errors appear.

For technical systems, check system health, storage capacity, CPU, memory, network connectivity, DNS resolution, certificates, services, scheduled tasks, database connectivity, and application logs.

Why this matters:

A system can appear restored but still have broken services, missing dependencies, bad configuration, expired certificates, or failed integrations.

# Step 2: Validate Restored Data

Confirm that restored data is present, complete, usable, and from the correct recovery point.

Check important files, records, databases, transactions, user folders, customer data, finance data, HR records, order history, website content, and application data.

Where practical, compare restored data against the last known good state or business records.

Why this matters:

Recovery is not complete if data is missing, corrupted, encrypted, outdated, duplicated, or restored to the wrong location.

# Step 3: Confirm Access and Permissions

Review who can access the restored system or data.

Check that users, administrators, vendors, guests, service accounts, groups, and shared accounts have only the access they need.

Confirm that former employees, temporary accounts, suspicious accounts, old vendor accounts, and unauthorized guests do not have access.

For cloud storage and SaaS platforms, check public links, external sharing, guest access, group membership, admin roles, delegated access, OAuth apps, and API keys.

Why this matters:

Restoring data or systems with unsafe access can recreate the exposure that caused or worsened the incident.

# Step 4: Confirm Security Controls Are Active

Before declaring the system recovered, confirm that protective controls are working.

Check MFA, endpoint protection, EDR or antivirus status, logging, alerting, firewall rules, VPN restrictions, encryption, patch status, secure configuration, email security, SaaS sharing controls, cloud audit logs, website protections, and admin access restrictions.

For public-facing systems, confirm HTTPS, TLS configuration, security headers, WAF or filtering rules where used, CMS/plugin updates, and exposed service status.

Why this matters:

A restored system should not return to production without the controls needed to detect or prevent the same incident from returning.

# Step 5: Confirm Backups and Monitoring Resume

After restoration, check that backup jobs are running again and monitoring is active.

Confirm backup schedules, backup destinations, retention, backup alerts, backup credentials, restore test options, system monitoring, uptime monitoring, endpoint reporting, log collection, and critical alert routing.

Why this matters:

A restored system without backups or monitoring is fragile. The company may not notice if it fails again or becomes compromised again.

# Step 6: Test Key Business Processes

Ask the business owner to test the actual work that depends on the restored system.

Examples include sending and receiving email, logging into SaaS tools, issuing invoices, processing payroll, viewing customer records, submitting website forms, processing orders, accessing shared files, approving payments, running reports, shipping goods, contacting customers, and completing service delivery tasks.

Do not rely only on IT confirmation.

Why this matters:

Technical recovery and business recovery are not the same. The business process owner must confirm the process works in real operating conditions.

# Step 7: Monitor for Recurrence

After validation, monitor the restored system closely for a defined period.

Watch for suspicious logins, new admin changes, endpoint alerts, malware detections, failed services, backup failures, public sharing changes, data export activity, unusual outbound traffic, website file changes, DNS changes, vendor access, user complaints, and repeated errors.

Why this matters:

Some incidents return after recovery because the cause was missed, credentials were reused, malware was restored, or a related system was still compromised.

# Step 8: Record Validation Results

Create a validation record for each restored system or business process.

Record:

• System, data, or process validated
• Business owner
• Technical owner
• Date and time validated
• Restore source used
• Data checks completed
• Access checks completed
• Security checks completed
• Backup checks completed
• Monitoring checks completed
• Business process checks completed
• Issues found
• Residual risks
• Approval status
• Next review date

Why this matters:

Validation records prove that recovery was checked, not assumed. They also support leadership review, insurance claims, customer questions, audits, and post-incident improvement.

# Technical Validation Checklist

Confirm:

• The system is reachable.
• Required services are running.
• Application logs show no critical errors.
• DNS records are correct.
• SSL/TLS certificates are valid.
• Database connections work.
• Integrations work.
• Storage capacity is acceptable.
• Time synchronization is correct.
• Patch level is acceptable.
• Endpoint protection is active.
• Logging is enabled.
• Alerts are working.
• Backups are running.
• Admin access is restricted.
• MFA is enabled where applicable.
• No unexpected public exposure exists.
• No suspicious activity is continuing.

# Business Validation Checklist

Confirm with the business owner:

• Required users can log in.
• Required data is present.
• Reports can be generated.
• Transactions can be processed.
• Customers can be served.
• Invoices can be issued.
• Payments or approvals work correctly.
• Payroll or HR records are correct, if relevant.
• Orders, tickets, or service tasks can continue.
• Website forms or portals work, if relevant.
• Manual workarounds are no longer needed or are documented.
• Any remaining limitations are understood.
• The process is safe to return to normal operation.

# Helpful Open Source and Affordable Tools

These tools can prove useful to accomplish the validation of restored systems.

# Practical Tool Stack for SMEs

# Very small company:

Use Uptime Kuma, Healthchecks.io, endpoint protection reports, backup platform reports, Microsoft 365 or Google Workspace audit logs, Security Headers, SSL Labs, and a simple validation checklist.

# Microsoft-based SME:

Use Microsoft Defender, Microsoft Entra logs, Microsoft Purview Audit, Microsoft 365 admin reports, backup console reports, Jira Service Management or Zammad, and Uptime Kuma.

# Google Workspace SME:

Use Google Admin audit logs, Google Workspace Alert Center, Drive sharing reports, endpoint protection reports, backup reports, Uptime Kuma, and a validation register.

# Website-heavy company:

Use Uptime Kuma, Security Headers, SSL Labs, Internet.nl, WPScan, Nuclei, Cloudflare dashboards, website logs, and business testing of forms, checkout, portals, and content workflows.

# Cloud-heavy company:

Use Prowler, ScoutSuite, Steampipe, Trivy, cloud-native logs, cloud-native monitoring, Wazuh where deployed, and recovery tickets for business validation.

# Technical cost-conscious company:

Use Zabbix, Grafana, Prometheus, Wazuh, osquery or Fleet, Nmap, Greenbone, Uptime Kuma, Healthchecks.io, and Zammad or GLPI.

# Validation Record Template

Use a simple validation record with these fields:

• System, data, or process
• Business owner
• Technical owner
• Restore source
• Date restored
• Date validated
• Data validation result
• Access validation result
• Security validation result
• Backup validation result
• Monitoring validation result
• Business process validation result
• Issues found
• Residual risk
• Approved for normal use
• Approved by
• Next review date

# Expected Outputs from This Section

At the end of this section, the company should have:

• Restored systems technically validated.
• Restored data checked.
• Access and permissions reviewed.
• Security controls confirmed.
• Backups and monitoring confirmed.
• Business processes tested by owners.
• Recurring suspicious activity monitored.
• Validation records completed.
• Residual risks documented.
• Approval for normal or limited use recorded.

# Objective

Recovery is not complete until the restored system works and can be trusted.

A company should leave this section able to say:

“We tested the restored system technically, confirmed the business process works, verified protections are active, and recorded approval to return to normal use.”

That is recovery validation.

---