Documentation (Every Organization’s Favorite Topic!)
(Subtitled: The Psychological Impacts of Sloppy Documentation)
Going through a regulatory or contractually required assessment or audit requires properly documented policies, processes, procedures and plans. Let’s set aside that these documents MUST reflect the current organizational environment from a technical as well as operational and administrative posture for the sake of focusing on the documents themselves.
There are two main constructs that need to be addressed in every document submitted for an assessment: Content and Foundation. The legal profession sometimes refers to “Foundation” as “Structure” but I contend that “Foundation” goes deeper than mere structure as I’ll explain. Let’s get into it…
Documentation Content
Documentation content is the information the document contains to support the topic. This information could be instructional, directional, legal, operational, you name it. The content of a procedure explaining how to make a peanut butter & jelly sandwich is all of that information that tells you how to make a peanut butter and jelly sandwich. Content runs the gamut.
Let’s look at an example:
User Account Management
Ver. 1.0
Effective Date: 1 JAN 2026
Organization XYZ manages user accounts of eight (8) different but related types:
Standard User Accounts (with no administrative privileges)
Privileged Access Accounts
Emergency Accounts
Service Accounts
Guest Accounts
Shared Accounts
Group Accounts
Accounts Acting on Behalf of a User
Already, in this example from the introduction of a document’s topic is User Account Management, we have learned that Organization XYZ manages eight (8) account types. All of this information is what is called document content...that information that supports the topic.
Document content changes as changes to the environment are made. As you can imagine, in a fast-paced environment, the content can change frequently…and should! These changes are likely to be the result of an organizational process called Change Management wherein each change is analyzed for the documentation that each change makes to supporting documentation. For example, let’s say a Change Request is made for a router change to the network infrastructure, whether physical or virtual. You can conclude that such a change would impact associated documentation such as a System Security Plan (SSP), network diagrams, a System Development Life-cycle (SDLC) and likely as related system design document, to the say the least.
Simply stated, documentation being impacted regularly through a change management process as well as organizational documentation becomes “living” meaning changes to content stays up to date with the environment as changes impact documentation.
Traceability
We can’t discuss documentation content, especially for an assessment without discussing the concept of traceability.
Before we dive into the definition, let’s pull forward our example:
User Account Management
Ver. 1.0
Effective Date: 1 JAN 2026
Organization XYZ manages user accounts of eight (8) different but related types:
Standard User Accounts (with no administrative privileges)
Privileged Access Accounts
Emergency Accounts
Service Accounts
Guest Accounts
Shared Accounts
Group Accounts
Accounts Acting on Behalf of a User
As stated previously, we can draw several conclusions from this introduction to User Account Management in Organization XYZ:
This document type is likely a process or procedure document describing the different account types and how they are managed;
We might also expect from the differing account types that, since XYZ is calling each type out separately, there is a different method of handling each type of account.
Casting assumptions aside for a minute, let’s take a look at the eight (8) numbered items from the example. Now, let’s say reading farther into the User Account Management document provided by Organization XYZ, we notice that there is only discussion of seven (7) account types. One is missing. This is the concept of traceability within a single document. Your information MUST align within the document. So, if you have eight (8) items listed, you MUST discuss the eight (8) items throughout the document.
Let’s look at a cross-document traceability issue this time between a POA&M and an SSP and hint hint….this one gets a lot of people into trouble!:
POA&M (reduced for brevity):
POAM ID | System Impacted | Deficiency
SYS-001 | XYZ-Workstation | Spam protection not automatically updating
SSP (reduced for brevity):
Assessment Objective | Title | Status
SI-08(02) Spam Protection Automatic Updates Implemented
Document traceability simply means: what you are saying in one document MUST match what is being said in another.
In this example, we can tell that Organization XYZ has identified a problem with their Spam solution in that it is not updating automatically as required. BUT, when you look at the associated SSP, Organization XYZ states that this solution is fully implemented….meaning operating as required.
Both CANNOT be true. There is a fundamental mismatch between these two pieces of information on these two documents which WILL trigger the assessment team to dig into this issue.
As a matter of fact, the mere fact that a deficiency is on a POA&M negates the status of “Implemented” on any other documentation.
Speaking as an assessor, I have seen these mismatches time and time again. They are easy enough to fix by ensuring crosschecking of documentation content.
Documentation Foundation
You can think of documentation foundation as the skeletal system of a document. Formatting, line spacing, indentation, fonts, alignment, page numbering, headers & footers, bulleting, etc. All of this information changes far less often than content…and shouldn’t! Think of it this way, how many times has your organization changed their Standard Operating Procedure (SOP) template? Stays pretty stagnant, right? Unless there is some regulatory change that forces the template change such as FedRAMP requiring a new SSP template, the odds of foundational changes to these documents is slim.
But why stop there? I contend that included in documentation foundation are additional concerns such as spelling, grammar, traceability (we’ll get into more detail on this later), punctuation, etc. While you could make a good argument for spelling, punctuation and grammar being part of the content, when problems like this occur in a document, they are usually not isolated. For example, when someone misspells a word, it typically occurs throughout the document and is not a single event. Thus, these issues become part of the document foundation because they impact the readability …aka flow of the document.
Let’s take a look at the same document as the previous example making a good case for these issues being part of the foundation.
User acount Management
Ver. 1.0
Efective Date: 1 JAN 2026
Organization XYZ manages user acounts of eight (8) different but related types:
Standard user Acounts (with no administrative privileges)
A.Privileged Access Acounts
2.Emergency Acounts
2.Service Acounts
guest Acounts
Shared Acounts
*Group Acounts
Acounts Acting on Behalf of a User
Now, admittedly this is an extreme case but proves my point about the reading flow. You can already see how multiple spelling, random capitalizations, grammar, alignment, bullet and indentation inconsistencies become largely structural in that they interrupt the reader’s comprehension flow. In most cases, the reader will become so “disoriented” to the content of the document that they will likely stop reading and return it for correction in situations where this is acceptable.
Psychological Impact
“You never get a second chance to make a first impression.” – Will Rogers
In every assessment, there are specific documents that are turned over to the external assessment team, whether it’s a 3PAO (FedRAMP), C3PAO (CMMC/171), IG, CSI, Defense Contract Management Agency (DCMA), etc. The list of those initial documents are specific to the type of assessment your organization is going through but several stay fairly standard: SSP, network diagrams, Plan of Action & Milestones (POA&M), policies, processes, procedures and plans to name a few. In some cases scans are added to this initial set. And usually, this initial set of documents is delivered to the external assessment team prior to a kickoff meeting with the exception of any contract negotiations meetings. These documents are the starting point for the organization to introduce its organization structure, processes, technology, etc. to the external assessment team. Hence, this initial set of documents becomes the de facto first impression!
Now, if you take a look back at our “messed up” example above, you can see why documentation foundation becomes every bit as important as the document content. The initial impression upon reading documents like this set the tone for the assessment. The impression being, if the organization’s documentation is this messy, how disorganized is the organization itself not to mention the organization’s information systems, processes, policies, etc. Your documentation content could be a good as gold and hit every mark for the assessor, but if your first impression is the visual impression from sloppy documentation, I can all but guaranty you the assessment team will be digging deeper! And per Will Rogers, you don’t get a do over!
Solutions
So what can an organization do to ensure documentation makes that critical good first impression?
If your organization can afford it, hire a documentation specialist.
Do not give documentation writing responsibility to just anyone…not everyone is an English Writing Major! Be strategic.
Always….always….always put more than one set of eyes on documentation.
DO NOT deliver documentation in a hurry. Plan ahead. Every organization has a responsibility to maintain documentation to support not only assessments but more importantly, the organization itself. For example, Mary Jones is your organization’s vulnerability scanning operator. Mary Jones has a family emergency is out for an extended period. Unless there is a written desk guide or procedure on how the organization runs vulnerability scans, how can anyone be expected to pick up that function while Mary is tending to her emergency? There should be a documented process or procedure for every task or function within the organization using the rule of thumb “If you don’t write it down, you don’t do it!”
Every documented process, procedure, desk guide, plan, agreement, etc., should be thoroughly and regularly tested for accuracy. (Some documents require testing on a required timeline such as the Incident Response Plan’s annual testing requirement.) Organizational processes and procedures ARE TESTED by the assessment team as part of the interview/demo phase of every assessment. This is to ensure that not only is your documented processes and procedures accurately reflect the current environment, it is also to test the proficiency of your functional staff in their role.
Make sure all documentation is considered “living.” You should not view documentation as a painful necessary evil just prior to an assessment, many of which occur every 1-3 years, at which point your documentation could be woefully out of sync with reality. As previously stated, each time an organization, organizational process, organizational system undergoes even a minor change, the impact to the organization’s documentation should be analyzed and brought up to date as needed in order to keep it current...hence “living” documentation.
Remember: content changes frequently (living); foundation changes rarely.
Firefly Managing Partner