Server audit checklist for infrastructure, security and continuity

1. Define the decision, scope and a repeatable baseline

Start with the decision: reduce risk before renewing support, explain instability, prepare a migration, review a provider or establish a baseline. The objective determines depth, participants, data, timing and deliverables. “Review everything” does not define when evidence is sufficient.

Connect servers to business services and agree concrete identifiers: hardware, virtual machines, subscriptions, accounts, zones, networks and environments. Record date, source, time zone, credential or role used and limitations. A screenshot without context ages quickly and cannot reproduce an observation.

• Decision that depends on the result and person responsible for making it.
• Assets, platforms, environments and business services included.
• Owners, providers and components explicitly excluded.
• Read methods, samples, periods and thresholds agreed.
• Initial state preserved before any remediation.

Server count alone does not determine effort: one instance can concentrate many dependencies and risks.

2. Build an inventory that explains dependencies and ownership

A hostname does not explain a system. Document function, version, location, environment, owner, criticality, data, applications, databases, storage, interfaces, certificates, DNS, schedules and dependencies. Confirm which users, processes, sites and third parties consume each service.

Look for orphaned, duplicate, temporary, unmanaged or unmonitored assets, including backup gaps. Connect each component to its source of truth and change process. When the inventory, cloud console and network disagree, preserve the discrepancy as a finding instead of silently choosing one version.

• Technical identifier, function, environment and accountable owner.
• Operating system, edition, version, support and relevant licensing.
• Applications, data, integrations, certificates and scheduled jobs.
• Networks, storage, virtualization, cloud and shared services.
• Upstream and downstream dependencies and outage effect.

What nobody owns rarely receives timely patches, recovery tests and decisions.

3. Review configuration, lifecycle and change discipline

NIST SP 800-128 treats security as part of configuration management: identifying and controlling configurations, changes and monitoring. Compare observed state with an approved baseline, vendor documentation and platform-relevant recommendations. CIS Benchmarks can supply prescriptive controls, but each deviation still needs context and a decision.

Review support, updates, repositories, firmware, services, modules, startup, jobs, configuration files, time synchronization and automation. Distinguish an available patch, applicable vulnerability, exposure and feasible change. Before hardening, confirm compatibility, testing, window, backup and rollback.

• Supported version, pending updates and lifecycle path.
• Approved baseline, exceptions, owner and review date.
• Unnecessary or unexplained services, modules, jobs and packages.
• Change history, configuration as code and environment separation.
• Change testing, approval, deployment, verification and rollback.

4. Verify identities, privileges, secrets and remote access

Enumerate human, service, local, directory, cloud and emergency accounts. Connect each to an owner, purpose, privilege, authentication, last use, rotation and offboarding process. Look for shared, old or non-expiring accounts, nested groups and services running with more permission than needed.

Review administrative paths: VPN, bastion, console, RDP, SSH, hosting panel, hypervisor and management tools. Confirm encryption, MFA where supported, source restriction, sessions, logging and separate administrator accounts. Do not copy secrets into the report; document the condition and location safely.

• Owner and purpose for every privileged or service account.
• MFA, keys, passwords, vaults, rotation and emergency access.
• Least privilege, temporary elevation and separation of duties.
• Offboarding, inactive accounts, third-party access and periodic reviews.
• Source, protocol, encryption and traceability of remote administration.

A service account without an owner often outlives the people, providers and application that created it.

5. Map network, exposure and trust boundaries

Connect interfaces, addresses, routes, DNS, ports, rules, load balancers, proxies, tunnels, segmentation and management services. Verify through authorized internal and external sources: listening on an interface alone does not prove internet exposure, and a cloud rule may contradict the system firewall.

Prioritize vulnerabilities with context. CISA’s Known Exploited Vulnerabilities catalog is a signal of known exploitation, not a substitute for inventory and applicability. Combine service criticality, accessible path, privilege, compensating controls, detection and recovery to determine urgency.

• Expected services compared with observed ports, interfaces and routes.
• User, server, backup, management and third-party segments.
• Duplicate, broad, old or unowned rules and their justification.
• TLS, certificates, legacy protocols and unencrypted administration.
• Applicable vulnerability, real exposure and remediation priority.

6. Analyze capacity, availability, monitoring and logs

A point-in-time reading does not demonstrate capacity. Review representative trends for CPU, memory, I/O, space, inodes, network, queues, processes, latency and job duration. Identify seasonality, peaks and competing workloads. Connect each threshold to perceptible degradation and the time available to act.

NIST SP 800-92 describes log management as a process: generation, transmission, storage, analysis and disposal. Confirm which events exist, who reviews them, retention, reliable time and alert behavior. A full log file or green dashboard without notification testing is not observability.

• Representative period, peaks, trend, headroom and saturation forecast.
• Redundant dependencies, single points and failure behavior.
• Metrics, events, traces and health checks that are actually consumed.
• Alerts with owner, severity, channel, escalation and a recent test.
• Retention, integrity, access, time synchronization and investigative value.

Measuring more is not observing better: each signal needs an interpretation and a response.

7. Demonstrate backup, restoration and continuity

Distinguish copy, replica, snapshot, high availability and backup. Define which data, system, configuration, secrets, certificates and code are needed to recover the service. Connect frequency and retention to acceptable recovery point (RPO), and procedure and capacity to recovery time (RTO).

NIST SP 800-34 guides contingency planning; CISA recommends encrypted, offline or protected critical backups and regular availability and integrity testing. Review jobs, failures, immutability or isolation, credentials, capacity and restores. A test needs a controlled target, criteria, timing, application validation and recorded gaps.

• Coverage of data, system, configuration, dependencies and required keys.
• RPO and RTO agreed by service rather than assumed from the tool.
• Separated copies protected from deletion with independent credentials.
• Failure alerts, retention, capacity, encryption and integrity evidence.
• Tested restoration, manual steps, actual time and business validation.

A successful job proves that it finished; it does not prove that the service can recover.

8. Turn evidence into a verifiable roadmap

Each finding should state condition, evidence, asset, affected service, likely cause, impact, exposure, limitation and recommendation. Separate facts from hypotheses. Avoid unexplained scores and recommendations such as “update everything”: provide options, dependencies, change risk, window and closure criteria.

Sequence actions by horizon: immediate containment, stabilization, debt reduction and sustained improvement. Assign owners and dates, integrate changes with backup and rollback, and preserve evidence before and after. NIST SP 800-61 Rev. 3 connects preparation, detection, response and recovery to risk management; use findings to improve monitoring and response as well.

• Reproducible finding with source, date, asset and limitation.
• Operational impact, exposure, detectability and recoverability.
• Recommended action, alternative, dependency and change risk.
• Owner, priority, target date and evidence required for closure.
• Post-change validation and accepted or pending residual risk.