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. They also exist to describe how you get the job done and stay profitable. 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 dictate 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 communicate the critical information about how your organization meets the requirements of NIST-SP-800-171.

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.

A flowchart outlines how system security plans (SSP) involve defining, identifying, and describing technical or procedural safeguards, incorporating assessments, gap analysis, and evidence gathering to ensure safeguards are adequate and sufficient, especially for micro-businesses.

Flavors of an SSP

We often see different types of SSPs. Those that explain procedures in the control statements and those that point to other documentation. Some companies try to do both. Some may define most procedures in their SSP. 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.

Smaller micro businesses may have even less documentation. Remember your System Security Plan serves a plan. You use it as a governing document. A company can include all your definitions, identify controls, and spell out procedures directly in the SSP. In fact a two person company dealing with 14 policies, 14 plans, and umpteen forms and Standard Operating Procedures leaves them less secure. Do they really need a password policy or just spell it out in the SSP?

In the first example when a requirement that has an objective which states you must DEFINE a “thing” you would write, Spacely Sprockets defines X as, “insert definition.” Then in the next objective, “We enforce the thing in our SOP Y “

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.” Then in the next objective, “We enforce the thing in our SOP Z “

In the last example when an objectives n the second example when an objective states you must DEFINE a “thing” you would write, “ Spacely Sprockets defines X as, “insert definition.” Then in the next objective, “We enforce the thing by doing 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. You will end up with forms that have a thousand columns. Do let machines invent new workflows. You will not do them.

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 provide value and help get the job done.
  • 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.