System Security Plan
A System Security Plan, commonly shortened to SSP, is the authoritative document that describes your information system, defines its boundary, and states exactly how each required security control is implemented. It is the single artifact an assessor reads first, and under NIST SP 800-171 control 3.12.4 it is itself a mandatory control. Petronella Technology Group writes assessment-ready System Security Plans for defense contractors, healthcare organizations, and regulated businesses in Raleigh, Durham, Cary, and nationwide.
Serving Raleigh, Durham & the Triangle / Since 2002 / CyberAB RPO #1449 / BBB A+ Since 2003
Key Takeaways
- A System Security Plan is not paperwork about your security program. Under NIST SP 800-171 control 3.12.4 the plan is a control in its own right, so an organization with no SSP has already failed at least one requirement before an assessment begins.
- The system boundary is the highest-leverage decision in the entire document. Draw it too wide and every workstation in the company inherits 110 controls. Draw it deliberately and the scope becomes affordable.
- The SSP and the Plan of Action and Milestones are complementary, not interchangeable. The SSP states what is implemented; the POA&M states what is not yet implemented and when it will be.
- Downloadable SSP templates fail assessments for a predictable reason: they contain the control text but not the implementation narrative, and assessors score the narrative.
- An SSP is a living document. DFARS 252.204-7012 and CMMC both expect it to reflect the system as it exists today, which means it must be revised whenever the environment changes.
Who Needs One
- Defense contractors and subcontractors handling Controlled Unclassified Information under DFARS 252.204-7012.
- Any organization pursuing CMMC Level 2 certification, where the SSP is reviewed by a C3PAO.
- Organizations reporting a Supplier Performance Risk System score, which must be traceable to a current plan.
- Healthcare organizations documenting administrative and technical safeguards under the HIPAA Security Rule.
- Companies preparing for a SOC 2 examination that need a coherent description of the system in scope.
What Is a System Security Plan?
The plain answer, before the compliance vocabulary arrives.
The short definition
A System Security Plan is a formal document that describes an information system, establishes the boundary of that system, identifies the security requirements that apply to it, and explains how each of those requirements is satisfied. It answers three questions in order: what is the system, what must protect it, and how is that protection actually implemented today.
Why it exists
Regulators and assessors cannot inspect every server in every organization. Instead they require a written, attestable description of the system and its controls, then sample against it. The SSP is that description. It converts a sprawling technical environment into something a third party can evaluate consistently.
Where the requirement comes from
NIST SP 800-171 requirement 3.12.4 directs organizations to develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. CMMC inherits this requirement directly.
What it is not
An SSP is not a policy set, not a network diagram, and not a vendor questionnaire. Policies state intent. The SSP states implemented reality. An organization can hold a complete policy library and still have no valid SSP, which is one of the most common findings we encounter during readiness work.
The Document an Assessor Opens First
Understanding how the SSP is used explains why most of them fall short.
How the plan is actually used
An assessor does not begin with your firewall. They begin with your System Security Plan, because the plan tells them what they are assessing and what you claim is true. From it they derive the boundary, the asset inventory, the control set, and the sampling strategy. Every interview question and every artifact request traces back to a statement in the plan.
This has a practical consequence that organizations consistently underestimate: the SSP defines the terms of your own assessment. A vague plan produces a broad, expensive assessment because the assessor must probe to establish what a well-written plan would have stated. A precise plan narrows the inquiry to what you have already documented.
Why templates fail
The market is full of downloadable System Security Plan templates, and they share a structural weakness. A template can supply the requirement text, the section headings, and the table layout, because those are identical for everyone. What a template cannot supply is the implementation narrative, because that describes your environment specifically.
Assessors score the narrative. A row that restates the control - saying that access is limited to authorized users for requirement 3.1.1 - conveys nothing. A row that names the identity provider, the group structure, the joiner and leaver process, the review cadence, and the evidence location is assessable. Templates get organizations to a document quickly and to a defensible document not at all.
What Goes Inside a System Security Plan
The components an assessment-ready plan is expected to contain.
System identification
The system name, a unique identifier, the responsible organization, the system owner, and the security contact. This section also records the operational status of the system and the date of the current revision, which is how an assessor confirms the plan is not stale.
System boundary
An explicit statement of what is inside the system and what is outside it. This is the section that determines cost and difficulty for everything downstream. It should name the networks, the enclaves, the cloud tenants, the endpoints, and the physical locations that are in scope, and it should be equally explicit about what is excluded and why.
System environment and architecture
A description of how the system operates: the hosting model, the network topology, the authentication architecture, the data stores, and the flow of regulated data through the environment. Diagrams support this section but do not replace the written description.
Data types and categorization
What regulated data the system processes, stores, or transmits. For defense work this means identifying Controlled Unclassified Information and its categories. For healthcare it means protected health information. The categorization drives which control set applies.
Control implementation statements
The core of the document. For each applicable requirement, a narrative describing how it is implemented in this environment, by which technology or process, under whose responsibility, and where the supporting evidence lives. This is the section that consumes the overwhelming majority of the effort.
Interconnections and inherited controls
Connections to other systems, and controls inherited from external providers such as a cloud service provider or a managed service provider. Inheritance must be stated explicitly, because an assessor will ask what evidence supports a control you did not implement yourself.
Roles and responsibilities
Named accountability for the system and its controls. Plans that assign everything to a generic function rather than a role tend to fail interviews, because the assessor asks a person to describe a process and no one owns it.
Revision history
A record of when the plan changed and why. Because the environment changes continuously, revision history is how an organization demonstrates that the plan is maintained rather than written once and filed.
Why the System Boundary Decides Your Cost
The one section where a few sentences change the size of the entire program.
The expensive default
The path of least resistance is to define the system as the company: every laptop, every server, every cloud service, every office. It requires no analysis and it is never wrong in the narrow sense. It is simply the most expensive possible answer, because every asset inside the boundary must satisfy all 110 NIST SP 800-171 requirements and produce evidence for each.
Organizations that take this path frequently discover the consequence late, when the remediation estimate arrives and covers hardware and processes that never touched regulated data in the first place.
The deliberate alternative
The alternative is to identify where regulated data genuinely lives and flows, then construct a defined enclave around it. Assets outside the enclave remain outside the assessment. This is the reasoning behind a CMMC enclave, and it is a boundary decision documented in the SSP rather than a product you purchase.
An enclave is not automatically the right answer. It introduces its own obligations around data movement and separation, and a boundary that does not match how people actually work will be contradicted the moment an assessor interviews staff. The decision is an engineering judgment, and it belongs at the beginning of the SSP effort rather than the end.
Not sure whether your boundary is defensible? We will review it before you write a single control statement, because a boundary correction after the fact means rewriting the plan. Call 919-348-4912 or request a scoping conversation.
The System Security Plan and the Plan of Action and Milestones
Two documents, two jobs, routinely confused.
The SSP states implemented reality
The System Security Plan describes what is in place now. Each control statement should be true on the day it is read. If multi-factor authentication is enforced for remote access, the plan says so and points to the evidence. The SSP is a description, and its credibility rests entirely on being accurate.
The temptation is to write the plan aspirationally, describing the environment as it will exist after remediation. This is the single fastest way to lose an assessment, because the assessor tests the statement and finds it false. A plan that overstates is worse than a plan that admits a gap.
The POA&M states the gap and the date
The Plan of Action and Milestones is where unmet requirements are recorded honestly: which requirement is not satisfied, what the remediation is, who owns it, and when it will be complete. Under DFARS the POA&M is an expected artifact, not an admission of failure.
Used correctly the two documents are a matched pair. The SSP marks a requirement as not implemented and cross-references the POA&M item; the POA&M carries the closure date. Read together they give an assessor a complete and truthful picture, which is precisely what the framework asks for. Our control-level guide to requirement 3.12.4 covers the linkage in detail.
The Fourteen Control Families an SSP Must Address
NIST SP 800-171 organizes its 110 requirements into fourteen families. An assessment-ready plan carries an implementation narrative for every applicable requirement in each.
The families are not equally difficult. Access Control, Audit and Accountability, and System and Communications Protection typically carry the heaviest implementation burden and generate the most assessment findings, because they depend on technical configuration that must be demonstrated rather than asserted. Personnel Security and Maintenance are lighter but are frequently neglected precisely because they are procedural, and a missing narrative is a finding regardless of how simple the underlying practice is. A structured risk assessment is the usual input to the Risk Assessment family and feeds several others.
System Security Plans Across Different Frameworks
The document has a different name and emphasis depending on which regulator is asking.
CMMC and NIST SP 800-171
The strictest use of the term. The SSP is mandated by requirement 3.12.4, reviewed by a C3PAO during a Level 2 certification assessment, and must align with the Supplier Performance Risk System score submitted to the government. Read our CMMC compliance guide for the wider certification path.
DFARS 252.204-7012
The contract clause that obligates defense contractors to implement NIST SP 800-171 and therefore to hold a System Security Plan. Our DFARS 252.204-7012 page covers the clause, its flowdown to subcontractors, and the incident reporting obligation that accompanies it.
HIPAA Security Rule
HIPAA does not use the phrase system security plan, but it requires documented administrative, physical, and technical safeguards and a documented risk analysis. In practice organizations satisfy this with an equivalent document. See our HIPAA compliance services for the healthcare-specific path.
SOC 2
A SOC 2 examination requires a description of the system in scope, which serves a similar function: defining the boundary and the controls that address the applicable Trust Services Criteria. Our SOC 2 compliance and readiness assessment pages cover the examination path.
Where System Security Plans Go Wrong
The recurring problems we find when reviewing an existing plan.
The control text is restated instead of implemented
The most common defect by a wide margin. The narrative for requirement 3.1.1 reads that the organization limits system access to authorized users, which is the requirement itself rather than a description of anything. An assessor reading this learns nothing and must construct the entire picture through interviews, which lengthens the assessment and multiplies the opportunities for a finding.
The boundary is undefined or contradicted elsewhere
Either the boundary section is vague, or it is precise but contradicted by the network diagram, the asset inventory, or an interviewee who describes working outside it. Internal contradiction is treated seriously because it suggests the plan does not describe the operating environment.
Inherited controls are claimed without evidence
An organization states that a control is satisfied by a cloud provider without identifying which provider offering, which service model, or which attestation supports the claim. Inheritance is legitimate and often necessary, but it must be traceable to a document you can produce.
The plan describes an aspirational environment
Controls are written as though remediation had already finished. This converts what would have been an honest POA&M item into a demonstrably false statement in the SSP, which is a materially worse position.
Evidence locations are missing
The narrative is accurate but never says where the supporting artifact lives. When the assessor requests evidence, staff search for it under time pressure. Naming the evidence location inside the control statement turns evidence collection into retrieval.
The plan is stale
The revision date is eighteen months old, the environment has since migrated to a new identity provider, and half the narratives describe systems that no longer exist. Because 3.12.4 requires periodic update, staleness is a finding against the control itself and not merely an inconvenience.
How Petronella Technology Group Builds a System Security Plan
A sequence designed so that the expensive decisions happen before the expensive writing.
Data flow discovery
Before anything is written we establish where regulated data actually enters, rests, moves, and leaves. This is done through interviews with the people who handle the data daily rather than from an architecture diagram, because the diagram reflects design intent and the interviews reveal practice. The gap between the two is usually where scope surprises live.
Boundary definition
With the data flow established, we propose a boundary and test it against how the organization works. If the boundary would require people to change their daily process, that change is identified now and costed, rather than discovered when an assessor interviews someone who works outside the documented enclave.
Control assessment against current state
Each applicable requirement is assessed as implemented, partially implemented, or not implemented, based on what we can verify rather than what is reported. Partial implementation is recorded as partial. This step produces the honest baseline that both the SSP and the POA&M depend on.
Narrative authoring
Implemented controls receive a specific narrative: the technology or process, the configuration, the responsible role, the review cadence, and the evidence location. Our engineers write these rather than a documentation specialist working from a questionnaire, because a narrative written without understanding the configuration reads exactly like a template.
POA&M construction and cross-referencing
Unmet requirements are moved into a Plan of Action and Milestones with owners and dates, and the SSP cross-references each one. The two documents are delivered as a matched pair so an assessor can move between them without reconciling anything.
Maintenance cadence
We establish what triggers a revision - a new system, a provider change, an identity migration, a boundary change - and who is responsible for making it. Because 3.12.4 requires periodic update, a plan without a maintenance process is a plan that will be non-compliant again within a year.
Downloadable Template vs Generic Consultant vs Petronella
What each approach delivers, and where each one structurally falls short.
| Capability | Petronella Technology Group | Downloadable Template | Generic Compliance Consultant |
|---|---|---|---|
| Environment-specific control narratives | Written by engineers who verified the configuration | Not possible, template is generic by definition | Varies, often written from a questionnaire |
| Boundary engineering before authoring | First step of the engagement | Left entirely to the buyer | Sometimes, frequently after drafting begins |
| CyberAB Registered Provider Organization | RPO #1449, team CMMC-RP certified | Not applicable | Depends on the firm |
| Verification of claimed controls | Assessed against observed configuration | None | Often self-attested by the client |
| Matched POA&M with cross-references | Delivered as a paired artifact | Separate template at best | Usually delivered, linkage varies |
| Evidence location recorded per control | Included in every narrative | No | Inconsistent |
| Ongoing maintenance and revision | Defined triggers and named owners | Buyer's responsibility | Typically a new engagement |
| Ability to remediate what the plan uncovers | Same team implements the fix | No | Advisory only in many cases |
ComplianceArmor and Living Documentation
Why documentation drifts
The reason most System Security Plans go stale is not negligence. It is that the plan is authored once as a static file, while the environment it describes changes weekly. An identity provider migration, a new cloud tenant, a replaced endpoint agent, a reorganized team - each one invalidates a handful of narratives, and nothing in a static document signals which ones.
The result is a document that was accurate on its publication date and progressively less accurate every day afterward, which is exactly the condition requirement 3.12.4 is written to prevent.
Treating the plan as a maintained artifact
ComplianceArmor is Petronella Technology Group's compliance documentation platform. It holds control narratives, evidence references, and framework mappings in one place so that a change is made once and reflected everywhere it appears, rather than hunted through a long document.
The platform supports the frameworks our clients are assessed against, including NIST SP 800-171 and CMMC, HIPAA, and SOC 2, which matters for organizations carrying more than one obligation. A single control frequently satisfies requirements in several frameworks, and maintaining that mapping by hand across separate documents is where multi-framework organizations lose the most time.
Who Writes Your Plan
Credentials behind the work
Petronella Technology Group has operated since April 2002 and has been BBB A+ rated since 2003. The firm is a CyberAB Registered Provider Organization, RPO #1449, and the team holds CMMC Registered Practitioner certification.
Craig Petronella, founder and CMMC Registered Practitioner, is the author of the CMMC 2.0 Certification Guide, which covers the maturity levels, the 110 NIST SP 800-171 controls, Supplier Performance Risk System scoring, and preparation for a C3PAO assessment. He is a Licensed Digital Forensics Examiner in North Carolina, license number 604180-DFE, holds MIT Sloan Executive Education certification in cybersecurity for managers, and has served as a cybersecurity expert witness for law firms.
The practical consequence for a System Security Plan is that the control narratives are written by people who have configured the controls, and reviewed by people who understand how a C3PAO will read them. Further background is available on our books page and the Encrypted Ambition podcast.
What clients say
"Craig takes the time to understand our business model, not just our technology stack. It makes his recommendations more strategic and tailored to our actual goals."
Daniel Lee, TrustIndex verified review
Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews. That comment describes exactly the difference that matters in System Security Plan work: a plan written by someone who understands how the business actually operates produces a boundary and a set of narratives that survive an interview, while a plan written from a form does not.
Already have a System Security Plan and want to know whether it will hold up? We will review the existing document against the requirement set and tell you specifically where it is thin, before you commit to an assessment date. Call 919-348-4912.
System Security Plan Services in Raleigh and the Triangle
Based in Raleigh, serving the Triangle and clients nationwide.
Petronella Technology Group operates from 5540 Centerview Dr., Suite 200, Raleigh, NC 27606, and works with defense contractors, manufacturers, healthcare organizations, and professional services firms across Raleigh, Durham, Chapel Hill, Cary, Apex, and the wider Research Triangle. North Carolina carries a substantial defense supplier base, and much of our System Security Plan work originates with organizations that received a DFARS flowdown from a prime contractor and needed a plan before a milestone they did not set.
Discovery and boundary work benefit from being on site, because the most useful information comes from watching how regulated data is genuinely handled rather than how a process document says it is handled. For Triangle clients we do that in person. For clients elsewhere in the country we run the same discovery remotely, and the deliverable is identical. To start a conversation, call 919-348-4912 or email info@petronellatech.com.
System Security Plan Questions
What is a System Security Plan?
Is a System Security Plan required for CMMC?
What is the difference between an SSP and a POA&M?
Can I use a downloadable System Security Plan template?
How long does it take to produce a System Security Plan?
How often does a System Security Plan need to be updated?
Who should write the System Security Plan?
Does a System Security Plan apply outside of defense contracting?
Get a System Security Plan That Survives the Assessment
Boundary engineering first, verified control narratives second, a matched Plan of Action and Milestones alongside it. Call 919-348-4912 or request a scoping conversation.
Petronella Technology Group, Inc. / 5540 Centerview Dr., Suite 200, Raleigh, NC 27606 / 919-348-4912 / Last Updated: August 2, 2026