- Admin access (or an admin's time) to verify logging settings in each source system
- The log platform's list of connected sources and their last-received timestamps
- Retention settings per source and platform, read from configuration rather than remembered
ATL-020MATRIXEDITORIAL REVIEW COMPLETE
Logging and Monitoring Coverage Matrix
One row per log source — identity provider, email, endpoints, firewall, servers, cloud audit, OT network sensor — answering the questions that matter when an incident starts: is it enabled, where does it go, how long is it kept, who actually looks at it, and what alerts fire.
Using this artifact
Purpose, inputs, and completion
Purpose. The first hour of every incident response is a race to the logs, and the losing version of that race discovers that the log needed most was never enabled, silently stopped forwarding, or aged out last month. This matrix is the standing answer: per source, whether logging is on, where it goes, how long it lives, who reads it, and what alerts on it. Its coverage percentage gives leadership one number to watch, and its gaps column turns blind spots into decisions instead of surprises.
When to use it. Work the matrix one row per log source, verifying each answer in the source system and testing forwarding into the log platform rather than trusting the configuration screen. Compute the coverage summary when the rows are done, then move every gap into the final section with an owner and a date — or a signed acceptance. Re-verify quarterly and within a week of any platform or retention change; forwarding breaks silently, and only re-verification notices.
- Verify each row in the source system itself, not from memory — 'logging is on by default' is the sentence that precedes most empty-log discoveries.
- Test forwarding per source by finding a known recent event in the log platform; a source can be enabled and forwarding nowhere.
- Name a person and a cadence in the reviewed-by column; a log nobody is assigned to read is storage, not monitoring.
- Cover OT passively: span- or tap-based sensors watching the production network, coordinated with the process owner and equipment vendors — never agents installed on controllers or HMIs.
- Compute the coverage summary and put the gaps column to work: every gap becomes a dated item in the final section, or an explicitly accepted blind spot with a named acceptor.
Keeping it honest
Evidence, validation, and failure modes
- A per-source, verified record of logging enablement, forwarding, retention, review, and alerting
- A coverage percentage with its computation date, comparable across quarters
- A gaps list with owners and dates — or signed acceptances for deliberate blind spots
- Generate a benign test event in two sources (a test sign-in, a firewall rule hit) and confirm both appear in the log platform within the expected delay.
- Pick one source marked 'reviewed weekly' and ask its named reviewer when they last looked and what they found; the pause before the answer is the finding.
What looks done but is not
- Everything is 'enabled' but half the sources forward nowhere, which is discovered during the first real incident — precisely when it cannot be fixed retroactively.
- Retention is assumed to be a year and is actually thirty days of platform default; the investigation needs day forty-five.
- The OT network is invisible because agent-based tooling cannot run there, and no one deployed the passive alternative — so production, the highest-consequence zone, is the least watched.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain the last eight quarterly matrices (two years); when an incident reveals a blind spot, the matrix history shows whether it was known, accepted, or simply never examined.
Full document
Preview — exactly what prints
MATRIX · LOGGING & MONITORINGv1.0 · REVIEWED 2026-08-06
Logging and Monitoring Coverage Matrix
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
The first hour of every incident response is a race to the logs, and the losing version of that race discovers that the log needed most was never enabled, silently stopped forwarding, or aged out last month. This matrix is the standing answer: per source, whether logging is on, where it goes, how long it lives, who reads it, and what alerts on it. Its coverage percentage gives leadership one number to watch, and its gaps column turns blind spots into decisions instead of surprises.
How to use it
Work the matrix one row per log source, verifying each answer in the source system and testing forwarding into the log platform rather than trusting the configuration screen. Compute the coverage summary when the rows are done, then move every gap into the final section with an owner and a date — or a signed acceptance. Re-verify quarterly and within a week of any platform or retention change; forwarding breaks silently, and only re-verification notices.
How to complete the matrix
Ground rules that keep the matrix a verified record rather than a wishful one.
Verification rules
- Enabled? is answered from the source system's own settings screen, checked today — not from the deployment notes.
- Forwarded? is answered by finding a known recent event from that source in the log platform, with the observed delay noted.
- Retention is read from configuration in both the source and the platform; the effective retention is the shorter of the two.
- Reviewed-by names one person and a cadence; alerting lists the two or three alerts that actually fire from this source, not the catalog of possible ones.
Coverage matrix
The common sources are pre-listed below; add rows for anything else that would matter at 2 a.m. during an incident.
Rows beginning EXAMPLE: show the expected shape — complete the pre-listed sources and add your own.
| Log source | Enabled? | Forwarded / retained where | Retention period | Reviewed by whom / cadence | Alerting on? | Gaps |
|---|---|---|---|---|---|---|
| EXAMPLE: Identity provider sign-ins | Yes — verified 2026-08-04 | Forwarded to log platform | 12 months (platform tier) | IT leader — weekly triage | Yes — impossible travel, legacy-auth attempts, new admin role | None |
| EXAMPLE: OT network sensor (span port) | Yes — passive collection only | Sensor console, on-site server | 6 months | OT engineer — weekly | Yes — new device on OT network, new external connection | No visibility on cell 4 yet — remediation logged below |
| Identity provider sign-ins and audit | ||||||
| Email platform (mail flow, admin audit) | ||||||
| Endpoints (EDR / OS logs) | ||||||
| Firewall / VPN | ||||||
| Servers (authentication, file access) | ||||||
| Cloud audit (tenant and admin activity) | ||||||
| Backup platform (job results, admin actions) | ||||||
| OT network sensor |
Coverage summary
One number, honestly computed: of the sources this matrix says matter, how many are enabled, forwarding, and reviewed?
Summary
| Log sources in scope (count) | Enabled and verified forwarding (count) | With a named reviewer and cadence (count) | Coverage percentage (forwarding ÷ in scope) | Computed by / date |
|---|---|---|---|---|
Report the percentage quarterly alongside the two or three gaps that most affect incident response. A number that never moves is as informative as a number that improves — both tell leadership whether monitoring is being run or merely owned.
OT visibility notes
Production visibility is collected differently, on purpose. Write down how yours works so nobody 'fixes' it with an agent rollout.
Passive collection only on the production network
No agents on controllers, HMIs, or anything that runs the process — endpoint tooling built for office machines can stall production equipment or void vendor support. OT visibility comes from passive, span- or tap-based network sensors, deployed in coordination with the process owner and the equipment vendors, during maintenance windows when switch configuration must change. If a monitoring improvement requires touching production network gear, it is an OT change: window, rollback, safety review.
OT collection record
| Sensor(s) and collection method (span / tap, location) | Production segments covered / not covered | Who reviews OT alerts, and with the plant on what cadence | Vendor coordination notes |
|---|---|---|---|
Gaps and remediation
Every gap from the matrix becomes a dated item here — or a signed acceptance. Undocumented blind spots are the only kind that should not exist.
Gap register
| Gap (source and what is missing) | Incident-response impact | Remediate or accept (accepted by whom, if accepted) | Owner and target date |
|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly, and within a week of any logging-platform, retention, or major system change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain the last eight quarterly matrices (two years); when an incident reveals a blind spot, the matrix history shows whether it was known, accepted, or simply never examined. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.