Folks often bemoan compliance or security as paperwork and checkbox exercises, but that misses the point of Document Control. Policies, Plans, and procedures exist to ensure your business does work in ways that meet laws and regulations. Too often we create these governance tools as an afterthought to prove they exist.

Consider your document control using an AS9100 lens. For those not in Aerospace manufacturing, where ISO 9001 an AS9100 often live, your Policies, Plans, and Procedures dictates how an organization creates, approves, distributes, and retires quality-critical information.

So What Goes into Your System Security Plan?

Your System Security Plan (SSP) must the critical information you must communicate about how your organization meets the requirements of NIST-SP-800-171.

The flowchart outlines the relationships between system security plans, control statements, and assessments such as gap analysis, showing how companies handle reference documents and evidence to prove compliance and safeguard adequacy.

Most importantly your SSP must provide value to you and your team (which might include just you).

At KNC Strategic services we break the SSP down into two parts. The front matter, which includes all the diagrams and evidence required by Security Assessment controls and a spreadsheet of implementation statements written at the objective level.

Two Flavors of an SSP

We often see two types of SSPs. Those that explain procedures in in the control statements and those that point to other documentation. Some companies try to do both. This really depends on the size of your team and the scope of your environment. A small company utilizing a file share service or a managed enclave might not want to have a ton of documents to manage. A medium or large manufacturer who must meet multiple frameworks might have existing Document Control procedures. They can keep their SSP always in compliance and not need to update it for any procedural change.

In the first example when an objective states you must DEFINE a “thing” you would write, Spacely Sprockets defines X as, “insert definition.”

In the second example when an objective states you must DEFINE a “thing” you would write, “ Spacely Sprockets defines X. The definition is maintained in Document Y.”

Which Flavor is Better

Chocolate, Vanilla, or burnt Wildberry. The choice belongs to you. Many assessors like the ease of having procedures spelled out in the SSP. Many small IT firms like having all the steps they take in one plan. As long as you have a robust traceability matrix how you arrange things in the bowl should not matter.

At KNC Strategic Services we follow the second approach and point to documentation. As a C3PAO DIBCAC does our assessments. Folks who come out of the Government and get trained on 53/RMF often use this model. The Government has a large scope, and don’t exactly meet the definition of small business

Some companies do try and do both. This can get dangerous. Now you have to ensure all your implementation statements match in your policies and procedure and also in your SSP control statement. Document drift presents a compliance risk. Though LLMs, commonly referred to as AI, might mitigate and/or exacerbate this issue.

If your company consists of just you, it can feel odd to send yourself a change request ticket, have yourself evaluate the risk and security implications, get yourself to approve the ticket, update the ticket when the change gets done, then mark the change closed.

Procedures get done by humans, even if written by AI. Keep them useful.

Utilizing AI

You can really harness AI to create documentation and run compliance checks against evidence. Yet you can also burn through tokens and create spreadsheet columns you never fill which become problems come assessment time.

As part of your Document Control you should have spelled out policy on AI policy and procedure generation. You can offload the cognitive task of writing, but not the contractual risk.

AI likes to get wordy. You will create overly complicated procedures not meant for a small business without strong human oversight,

I have found this system works best for me.

  • Have a Policy, Plan, or Procedure template file employees must use in their model. You might add sensitivity labels if the document should not leave your approved AI boundary.
  • Create a boundary diagram and a data flow diagram. The more detailed and accurate of an image you provide of system boundaries the better your results.
  • Create the Policies, these just describe the regulations you meet and rarely change. Your goal is concise vagueness describing the specific regulations you meet.
  • Inventory your Procedures. How do you currently do stuff? Have you written these things down or does it fall in the “Institutional Knowledge Bucket”?
  • Upload any documentation from vendors such as SRMs, implementation guides, or installation steps.
  • Draft your NIST-SP-800-171a implementation statements.
  • Even if you uploaded NIST-SP-800-171a, the CMMC Assessment Procedures, and the Level One and Level Two scoping guides, go one control statement at a time. AI will straight make up objectives and new compliance requirements. Go slow to go fast.
  • Create or revise procedures to make sure the implementation statements happen. Do this close to the ground. Procedure must be useful.
  • Create a Plan for each Domain Family. Upload any relevant SOPs and the implementation statements. Ask AI to craft a plan
  • Delete all the extra kruft you do not need
  • Have Plans approved.

You may have your own system, and AI can create governance documents. Agents can keep all this aligned and gather evidence to ensure the SOPs get followed, but they can’t lead. Having document control matters so much more than checking a box for compliance.

You need to create systems that help you do business better.