IT Top 10 Implementation Checklist

Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.

Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.

Purpose

Every implementation step and validation check for the ten IT practices, generated from the live practice guides and ordered by the Resource Center's recommended sequence.

How to use it

Work top to bottom. A practice is not deployed until its validation checks pass, and it is not measured until you can put a number in the final column of its metrics table.

Scoring ladder

This checklist doubles as a maturity baseline. Record a level per practice as you work through it.

Score each practice against this ladder. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.

Level	Name	What it means	The question that separates it from the level below
0	Absent	The capability does not exist in any form.	Is there anything at all — a tool, a document, a person who owns it?
1	Documented	Intent exists on paper. Deployment has not happened or is incomplete.	Is the intent written down, with a named owner and a scope?
2	Configured	The technology or process is configured, but not yet applied to the intended scope.	Is it switched on and set up somewhere — even if only in part of the estate?
3	Deployed	It is applied across the scope it was meant to cover.	Does it cover everything in scope, with the exceptions written down?
4	Operating	It functions consistently during normal operations, not only when someone is watching.	Does it keep working through a normal month without manual rescue?
5	Measured	Coverage and effectiveness are measured, monitored, and exception-handled.	Can you state a number for coverage or effectiveness, and show the trend?
6	Governed	Ownership, scheduled review, continuous improvement, and evidence retention are established.	Is there an accountable owner, a review cadence, and retained evidence?

IT-01 — Phishing-Resistant Multi-Factor Authentication (MFA)

Stage 1 · Know and control · Owner: Identity administrator · Effort: Medium · Cost band: Low to medium

Passwords alone are not enough. Phishing-resistant MFA — FIDO2 security keys, platform passkeys, or PIV — removes the shared secret an attacker can steal. Start with privileged and remote-access accounts, then expand to the full workforce.

Implementation steps

Inventory identity providers and privileged accounts.
Choose a phishing-resistant method your stack supports: FIDO2, passkeys, or PIV.
Enforce MFA for admins and remote access first; measure coverage.
Block legacy authentication that bypasses MFA.
Document fallback, recovery, and break-glass procedures.

Validation

Run these before recording the practice as deployed.

Attempt sign-in with password only on a test account — it must fail.
Review sign-in logs for legacy-protocol authentications; target zero.
Confirm coverage by privilege tier: enrolled accounts divided by active accounts.

Operating metric	How it is calculated	Directional target
Phishing-resistant coverage — privileged	Privileged accounts enrolled on a phishing-resistant method ÷ all active privileged accounts.	100%, with every exception dated and owned.
Phishing-resistant coverage — workforce	All active accounts enrolled ÷ all active accounts.	Rising each month toward full coverage.
Legacy authentication events	Sign-ins over protocols that cannot present a second factor, counted monthly.	Zero, or an explicit allow-list with an end date.

IT-02 — Comprehensive Asset Inventory Management

Stage 1 · Know and control · Owner: IT leader · Effort: Medium · Cost band: Low to medium

You defend what you can see. A comprehensive inventory covers hardware, cloud and on-prem software, and — increasingly — identities and service accounts. Build it from authoritative sources, reconcile the sources against each other, and keep it current through change control rather than an annual scramble.

Implementation steps

Assign an accountable inventory owner with authority across IT and cloud.
Seed the inventory from authoritative sources: MDM/endpoint manager, identity provider, DNS/DHCP, cloud consoles, and procurement.
Reconcile the sources against each other and investigate anything that appears in one but not the others.
Extend beyond hardware to SaaS applications, service accounts, and privileged identities.
Connect the inventory to onboarding, offboarding, and change control so it stays current by default.

Validation

Run these before recording the practice as deployed.

Pick ten devices from the network at random; all ten must appear in the inventory with an owner.
Compare the identity provider's active accounts against the HR leaver list — there should be no orphaned accounts.
Confirm the last device added to the network appears in the inventory.

Operating metric	How it is calculated	Directional target
Managed coverage	Devices carrying a management agent ÷ devices observed on the network or in the identity provider.	Above 95%, with the remainder explained.
Ownerless assets	Inventory rows with no named owner.	Zero.
Orphaned accounts	Active accounts with no matching current employee or approved service purpose.	Zero at each monthly reconciliation.

IT-05 — Logical Segmentation to Limit Adversary Lateral Movement

Stage 2 · Contain compromise · Owner: Network administrator · Effort: High · Cost band: Medium to high

A flat network turns one compromised laptop into access to everything. Logical segmentation — VLANs, host firewalls, identity-based access, and separated management planes — breaks the network into zones so an intruder who lands in one place cannot freely reach the rest. Start by isolating the crown jewels and the riskiest devices.

Implementation steps

Map where sensitive data and critical systems live and who legitimately needs to reach them.
Define network zones by function and trust — user, server, management, CUI, guest, and high-risk devices.
Enforce controls between zones (firewalls, ACLs, host firewalls) with a default-deny posture.
Move privileged management traffic to a separate, tightly controlled plane.
Log and monitor traffic that crosses zone boundaries so unexpected movement is visible.

Validation

Run these before recording the practice as deployed.

From a standard user device, attempt to reach a server-zone or management interface — it must be blocked.
Confirm CUI systems are not directly reachable from the general user or guest network.
Review firewall/ACL rules for any “any-any” permit that undoes the segmentation.

Operating metric	How it is calculated	Directional target
Any-any rules	Firewall or ACL rules permitting unrestricted traffic between zones.	Zero outside a dated, owned exception.
Segmentation test result	Blocked cross-zone attempts ÷ attempts in the periodic test.	100% of the paths the design says should be blocked.
Assets in the correct zone	Inventory rows whose network placement matches the zone design.	Above 95%, with the remainder investigated.

IT-03 — Strategic Technical Debt Reduction

Stage 3 · Reduce exposure · Owner: IT leader · Effort: High · Cost band: Medium to high

Technical debt is a security liability. End-of-life operating systems, unpatched appliances, and legacy protocols are the footholds adversaries count on you keeping. Treat retirement as a planned program: find the debt, rank it by exposure, and either upgrade, replace, isolate, or decommission it on a schedule.

Implementation steps

Use the asset inventory to find unsupported, end-of-life, and unmaintained systems and protocols.
Rank each by exposure (internet-facing, holds CUI, widely reachable) and by business dependency.
For each, choose a path: upgrade, replace, isolate behind compensating controls, or decommission.
Sequence the work into a funded roadmap and put executive weight behind the deadlines.
Track end-of-support dates in the inventory so future debt is retired before, not after, it goes unsupported.

Validation

Run these before recording the practice as deployed.

Confirm no internet-facing system is running unsupported software.
Verify legacy protocols are disabled by testing that they no longer negotiate.
Check that each remaining legacy system has a dated retirement or isolation plan.

Operating metric	How it is calculated	Directional target
Unsupported systems in production	Systems running software past vendor end-of-support.	Trending to zero; none internet-facing at any point.
Legacy protocol availability	Services still negotiating deprecated protocols, tested rather than assumed.	Zero outside a dated, owned exception.
Roadmap adherence	Retirement milestones completed ÷ milestones due.	Above 80% each quarter.

IT-06 — Risk-Based Vulnerability Management

Stage 3 · Reduce exposure · Owner: IT leader / MSP · Effort: Medium · Cost band: Medium

You will never fix every vulnerability, so fix the ones that matter first. Risk-based vulnerability management pairs regular scanning with prioritization by exploitability and exposure — known-exploited vulnerabilities and internet-facing systems go to the front — and drives remediation against agreed timelines you actually meet.

Implementation steps

Deploy authenticated vulnerability scanning across endpoints, servers, cloud, and network devices.
Prioritize findings by real risk — known-exploited status and internet exposure ahead of raw CVSS.
Set and agree remediation SLAs by severity, and align them with your patch process.
Remediate on schedule; where you cannot patch, document a compensating control and a deadline.
Track remediation rates and mean-time-to-remediate, and feed misses back into the process.

Validation

Run these before recording the practice as deployed.

Confirm the last authenticated scan actually covered the full asset inventory, not a subset.
Verify critical and known-exploited findings were remediated within their SLA.
Check that exceptions have a documented compensating control and a review date.

Operating metric	How it is calculated	Directional target
Scan coverage	Assets successfully scanned with credentials ÷ assets in the inventory.	Above 95%; unscannable assets explained.
Mean time to remediate — critical	Average days from detection to remediation for critical and known-exploited findings.	Within the policy window, trending down.
Open known-exploited findings	Findings on the known-exploited catalogue still open past their window.	Zero.

IT-09 — Resilient Backup and Disaster Recovery Architecture

Stage 4 · Recover operations · Owner: IT leader · Effort: Medium · Cost band: Medium

Ransomware assumes your backups fail. A resilient architecture keeps at least one copy offline or immutable, protects backups with separate credentials and MFA, and — most importantly — proves recovery by testing restores against defined objectives. Backups you have never restored are a hope, not a plan.

Implementation steps

Identify critical systems and CUI, and confirm each is covered by backup.
Apply 3-2-1: three copies, two media, one off-site — with at least one offline or immutable.
Protect backups with credentials separate from production, MFA, and least-privilege access.
Define RTO (how fast) and RPO (how much data loss) for each critical system.
Test restores on a schedule and run scenario exercises so recovery is proven, not assumed.

Validation

Run these before recording the practice as deployed.

Perform an unannounced test restore of a critical system and time it against the RTO.
Confirm backup admin accounts are separate from production admins and require MFA.
Verify at least one backup copy cannot be altered or deleted from the production environment.

Operating metric	How it is calculated	Directional target
Backup coverage	Critical systems with a verified successful backup in the last cycle ÷ critical systems.	100%.
Tested restore time	Elapsed time of the most recent test restore, compared with the recovery-time objective.	Within the objective; gaps documented and funded.
Immutable or offline copies	Critical datasets with at least one copy that production credentials cannot alter or delete.	100%.

IT-04 — Flexible Technology Stack

Stage 5 · Engineer securely · Owner: IT leader · Effort: Medium · Cost band: Medium

Lock-in is a risk multiplier. A flexible stack — built on documented baselines, standard interfaces, and portable data — lets you replace a weak or end-of-life component without re-architecting the business. The goal is not novelty; it is the ability to change safely when a product, threat, or requirement changes.

Implementation steps

Document baseline, hardened configurations for core systems so “known good” is written down.
Centralize authentication and authorization on one identity provider instead of per-app logins.
Prefer standard, well-supported interfaces over bespoke integrations that are hard to unwind.
Keep data portable — verify you can export critical data in an open, documented format.
Put new tools through a secure-configuration checklist so every addition inherits the baseline.

Validation

Run these before recording the practice as deployed.

Pick a core system and confirm its documented baseline matches what is actually deployed.
Verify a critical dataset can be exported and re-imported without loss.
Confirm new applications authenticate through the central identity provider, not local accounts.

Operating metric	How it is calculated	Directional target
Baseline coverage	Core systems with a current documented baseline ÷ core systems.	100% of systems classified as core.
Central authentication	Applications authenticating through the central identity provider ÷ all business applications.	Rising toward full coverage; local-account exceptions dated.
Configuration drift	Systems where deployed configuration differs from the documented baseline.	Investigated within the agreed window; zero unexplained.

IT-07 — Integrate Security Early in the Development Lifecycle

Stage 5 · Engineer securely · Owner: Engineering lead · Effort: Medium · Cost band: Medium

Security bolted on at the end is expensive and leaky. Building it in — threat modeling, secure coding standards, automated testing in the pipeline, dependency and secret scanning, and reviewed changes — catches weaknesses when they are cheap to fix. This applies whether you ship software products or just maintain scripts, pipelines, and cloud infrastructure-as-code.

Implementation steps

Require peer review for code and infrastructure-as-code changes, and keep secrets in a vault, not in repos.
Add automated checks to the pipeline: static analysis, dependency/SCA scanning, and secret scanning.
Adopt a secure-coding standard and threat-model the most sensitive components.
Fail builds on critical findings so insecure changes cannot ship silently.
Track findings to closure and feed recurring issues back into standards and training.

Validation

Run these before recording the practice as deployed.

Attempt to commit a test secret — the pipeline should detect and block it.
Confirm a build with a known-critical dependency vulnerability fails as configured.
Review recent merges to verify each had a reviewer and passed the security gates.

Operating metric	How it is calculated	Directional target
Pipeline gate coverage	Production-bound repositories with SAST, dependency, and secret scanning enabled ÷ all such repositories.	100%.
Secrets in source control	Live credentials detected in repositories or history.	Zero; every historical finding rotated.
Critical findings past window	Critical pipeline findings open beyond the agreed remediation window.	Zero.

IT-08 — Secure AI Adoption and Data Protection

Stage 5 · Engineer securely · Owner: Engineering lead · Effort: Medium · Cost band: Low to medium

AI is entering the workplace whether you plan for it or not. Secure adoption means deciding — before staff paste data into a chatbot — which tools are approved, what data may and may not go into them, and how AI use is governed and logged. The goal is to capture AI's value without leaking CUI or feeding sensitive data into systems you do not control.

Implementation steps

Inventory the AI tools already in use — including browser extensions and embedded assistants.
Decide which tools are approved and require enterprise terms that prohibit training on your data.
Publish an AI acceptable-use policy that classifies what data may and may not be entered.
Provide sanctioned tools so staff have a compliant option, and route access through managed identities.
Log AI usage and extend data-loss prevention to detect CUI or sensitive data heading to AI services.

Validation

Run these before recording the practice as deployed.

Confirm the approved AI tools' terms prohibit using your data for training.
Test that a data-loss rule flags a document marked CUI when sent to an AI tool.
Review usage logs for access to unapproved public AI services.

Operating metric	How it is calculated	Directional target
Sanctioned-tool share	AI sessions through managed accounts ÷ observed AI sessions.	Rising toward full coverage.
Sensitive-content interceptions	Data-loss events where controlled content was heading to an AI service.	Detected every time; trending down as training lands.
Vendor terms review	Approved tools whose data-retention and training terms were re-verified this period.	100% at each review cycle.

IT-10 — Continuous Technical Workforce Readiness

Stage 6 · Sustain performance · Owner: Executive sponsor · Effort: Low · Cost band: Low

Tools do not defend anything on their own — people operate them. Continuous readiness means role-based training for the staff who run identity, endpoints, cloud, and response; hands-on exercises that build muscle memory; and keeping pace as your stack and the threats change. It is the cheapest of the basics and the one that makes the rest work.

Implementation steps

Define the technical roles that operate your defenses and who holds each today.
Map each role to the specific competencies it requires and identify the gaps.
Schedule role-based training — hands-on where possible — against those gaps.
Practice with tabletop and hands-on exercises so skills are rehearsed before an incident.
Cross-train critical functions and track readiness so it keeps pace with your stack and the threat.

Validation

Run these before recording the practice as deployed.

Confirm each critical defense has more than one person able to operate it.
Verify role-based training was completed for staff in technical roles this cycle.
Check that the last exercise produced documented lessons that changed a runbook or plan.

Operating metric	How it is calculated	Directional target
Single-person dependencies	Critical capabilities with only one competent operator.	Zero.
Role-based training completion	Technical staff current on their role's required training ÷ technical staff.	Above 90% each cycle.
Exercise-to-improvement rate	Exercises that produced a documented change to a runbook or plan ÷ exercises run.	100% — an exercise that changes nothing was not a test.

Limitations

What this asset is and is not

This is independent educational material. It supports planning and evidence collection; it does not establish compliance with NIST SP 800-171, DFARS 252.204-7012, CMMC, export-control obligations, or any contract requirement, and it is not an assessment. Tailor every item to your own technical, operational, contractual, regulatory, and safety requirements.

All downloads

Printing produces a paginated document. Choose “Save as PDF” in the print dialog and name it batb-it-top-10-implementation-checklist to keep filenames consistent across your team.