- The current org chart or staff list, including provider contacts
- The service agreement with any MSP, to separate what a provider performs from what it can be accountable for
- The practice owners already named on existing artifacts, so the matrix agrees with the rest of the library
ATL-004MATRIXEDITORIAL REVIEW COMPLETE
Security Roles and Responsibilities Matrix
A named-person accountability matrix across the security outcomes a small contractor must actually run — identity, inventory, patching, backup, log review, incident reporting, supplier security, training, evidence — so that every area has one accountable human, not a team name, a vendor, or a shrug.
Using this artifact
Purpose, inputs, and completion
Purpose. Security outcomes fail in the gap between 'someone should' and 'this person does'. This matrix closes that gap by naming, for each responsibility area, the one accountable person, who actually performs the work, who must be kept informed, and who owns the evidence that the work happened. It is the document that turns a list of good intentions into a set of individual commitments.
When to use it. Complete it in one sitting with the executive sponsor present, because accountability is assigned downward, not volunteered. Write real names — the moment a cell says a team, a role, or a vendor, that cell is unowned. Revisit quarterly and at every staffing change; a matrix naming departed people is worse than no matrix, because it answers the accountability question wrongly with confidence.
- Fill the Accountable column first, with one named person per row — if two names want the same cell, the row needs splitting.
- Record who performs the work separately from who is accountable; a provider can perform, only an employee can be accountable.
- Name an evidence owner for every row and check that person appears in the evidence index.
- Set a review date per row and log unfilled rows in the gaps section with an interim owner and a resolve-by date.
Keeping it honest
Evidence, validation, and failure modes
- A dated accountability record naming one person per security outcome
- A performs/accountable separation that makes provider responsibilities explicit and bounded
- A gap-and-handoff log showing coverage was managed through staff changes, not rediscovered after them
- Pick three rows and ask each named accountable person, cold, what they are accountable for; a blank look means the matrix is a document, not an agreement.
- Compare every Accountable cell against the current staff list; any name that has left the organization fails the matrix on the spot.
What looks done but is not
- Team names or vendor names in the Accountable column — 'IT' and 'the MSP' cannot be called at 2 a.m. and cannot be held to anything.
- The same overloaded person accountable for every row, which reads as coverage and operates as a single point of failure.
- Departures handled by deleting the name and leaving the cell blank, so nobody owns the area for months and no one notices.
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 superseded versions for at least two years; who was accountable when is exactly the question an incident review asks.
Full document
Preview — exactly what prints
MATRIX · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
Security Roles and Responsibilities 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
Security outcomes fail in the gap between 'someone should' and 'this person does'. This matrix closes that gap by naming, for each responsibility area, the one accountable person, who actually performs the work, who must be kept informed, and who owns the evidence that the work happened. It is the document that turns a list of good intentions into a set of individual commitments.
How to use it
Complete it in one sitting with the executive sponsor present, because accountability is assigned downward, not volunteered. Write real names — the moment a cell says a team, a role, or a vendor, that cell is unowned. Revisit quarterly and at every staffing change; a matrix naming departed people is worse than no matrix, because it answers the accountability question wrongly with confidence.
How to use this matrix
Each row is a security outcome the organization has decided to run. Accountable means the one person who answers for the outcome — including for the parts a provider performs. Performs means whoever does the hands-on work, internal or external. Informed means who must hear about failures without asking. Evidence owner means who can produce proof the work happened, on request, without a scramble.
One name per cell in the Accountable column
Not a team, not a title alone, not a company. 'J. Rivera (IT lead)' can be asked a question and give an answer; 'IT' cannot. If no employee can be named for a row, that row is a gap — log it below rather than papering over it with a vendor's name.
Responsibility areas
The starter rows cover the outcomes most small contractors must run; add rows for anything your environment adds and delete nothing silently.
Rows beginning EXAMPLE: show the expected shape — replace them with your own, then complete the remaining rows.
| Responsibility area | Accountable (named person) | Performs the work | Informed | Evidence owner | Review date |
|---|---|---|---|---|---|
| EXAMPLE: Patching — workstations and servers | J. Rivera (IT lead) | MSP, monthly ticketed cycle | Executive sponsor | J. Rivera (IT lead) | 2026-11-01 |
| Identity and access (joiners, movers, leavers, MFA) | |||||
| Asset inventory upkeep | |||||
| Backup and restore testing | |||||
| Log review and alert follow-up | |||||
| Incident reporting (internal and contractual) | |||||
| Supplier and provider security | |||||
| Security training and awareness | |||||
| Evidence retention and the evidence index | |||||
Rules for a matrix that holds up
- Exactly one named accountable person per row
- Shared accountability is no accountability; split the row instead.
- Providers appear in Performs, never in Accountable
- The contract makes a provider perform; only an employee answers for the outcome.
- Every evidence owner named here also appears in the evidence index
- No review date older than the review frequency
- A stale date means the row has not been looked at — treat it as unverified.
- Each named person has seen and accepted their rows
- Assignment without acknowledgment is a surprise scheduled for the worst moment.
Gaps and handoffs
Unfilled rows and staffing changes land here with an interim owner and a date — never as silent blanks in the table above.
Open gaps and pending handoffs
| Responsibility area | Gap or handoff (what changed) | Interim owner | Resolve by |
|---|---|---|---|
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 two weeks of any departure or role change among the named persons |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded versions for at least two years; who was accountable when is exactly the question an incident review asks. |
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.