Stop Writing SSPs Like Paperweights

Paul Netopski

I- I- I can't tell you how many times I've walked into an assessment, and the organization hands me this, this massive, three-hundred-page three-ring binder. They're smiling, they think they've aced it. But the second we start flipping through the pages, we find it's just this giant, bloated paperweight. It's filled with copy-pasted policy text, outdated procedures, and- and practically zero evidence. It's a compliance nightmare waiting to happen.

Roz the Rulemaker

Well, Paul, from a regulatory standpoint, that is the classic trap. Agencies and organizations often treat the System Security Plan, or the SSP, as a catch-all dumping ground. They think if they write down everything they could possibly do, they've satisfied the Administrative Procedure Act or the NIST SP 800-171 guidelines. But they confuse a strategic regulatory directory with an operational instruction manual. The Administrative Procedure Act requires clear, demonstrable procedures, not just regulatory aspirations.

Eric Marquette

So, wait... you're saying they're putting too much of the actual instructions inside the SSP itself instead of linking out? Like, trying to write the step-by-step guide for changing a password directly in the security plan?

Paul Netopski

Exactly, Eric! That's the core mistake. The SSP is supposed to state the what and the why, not the detailed, step-by-step how. That how belongs in separate, controlled procedure documents. The SSP should act as a directory. It- it should refer out to those external procedures, policies, and- and most importantly, the evidence artifacts. When you try to copy-paste your entire Active Directory configuration procedure into the SSP, the second you change a single setting, your SSP is out of date. It becomes a stale document instantly.

Roz the Rulemaker

And that is where the legal and compliance wheels fall off. Under NIST SP 800-18 and SP 800-171, accuracy is paramount. If your SSP describes a system state that doesn't match reality because someone updated a procedure but forgot to edit the giant SSP document, you are technically out of compliance. You've created a self-inflicted vulnerability during an audit.

Eric Marquette

So, the SSP is the map, not the actual roads. But how do you start building this map? Where does the foundation actually go?

Paul Netopski

You have to start with a rock-solid authorization boundary and a clean mapping of your information types. If you don't know where the system ends and where your Controlled Unclassified Information, or CUI, actually lives, nothing else matters. You're- you're basically building a house on sand. You need to define exactly what hardware, software, network segments, and cloud services are inside that boundary. You have to trace the flow of CUI across every single device, whether it's a virtual server or a portable laptop.

Roz the Rulemaker

And that mapping must align directly with the National Archives' CUI Registry. You can't just wave your hands and say, oh, we protect export-controlled stuff. You need to identify the specific categories, like CUI ITAR or CUI Export Controlled, and cite the precise statutory or regulatory authority governing that data. If you don't anchor your SSP in those legal authorities, you can't justify your scoping decisions to an assessor.

Paul Netopski

Let's- let's talk about the control blocks themselves. Every assessor's absolute favorite red flag is when they look at a control statement, say for 3.1.1, and the organization wrote, we have a firewall. That's it. No detail, no context, just we have a firewall. It's- it's completely useless.

Roz the Rulemaker

Which completely fails the evidentiary standards of any formal assessment. To withstand an audit, every single control statement needs a structured, standardized anatomy. You have to break it down into explicit fields. The template we use breaks this down into Aspect, Scope, Automated versus Manual, Inheritance, and CUI Relevance. Each one of these serves a specific legal and functional purpose.

Eric Marquette

Let's break those down. What do you actually write under Aspect, for example?

Paul Netopski

Aspect is where you state exactly what this system does to satisfy that specific requirement. You name the tool, the specific version, the specific configuration detail, and- and how often it runs. Like, instead of saying we use multi-factor authentication, you state, MFA is enforced for all privileged accounts using Microsoft Authenticator TOTP via conditional access policy CAP-MFA-001. You see the difference? It's specific, it's testable.

Roz the Rulemaker

Then you have Scope. You must define exactly what the control applies to. Is it all users? All endpoints? Only specific enclaves? If there are exclusions, you must document them and provide the regulatory justification for why that exclusion is acceptable. You can't leave any room for assumption.

Paul Netopski

Right, and then you- you specify if it's automated or manual. If it's manual, who does it and how often? Is it weekly, monthly, annually? If it's automated, what tool is driving it, like a SIEM or a configuration management database? Then there's Inheritance, which is massive. Are you inheriting this control from a cloud provider like AWS GovCloud, or is it fully organization-owned? And finally, CUI Relevance. You have to explain exactly how this control protects CUI. Where does CUI reside relative to this control's enforcement point?

Eric Marquette

That makes sense. It- it actually connects the technology back to the data it's supposed to protect. But how does an assessor verify any of this? They aren't just taking your word for it, right?

Paul Netopski

Absolutely not. This is where the Evidence Table comes in, and it's the absolute heart of a defensible control block. For every single control, you must reference concrete, verifiable artifacts. If you don't list evidence, the control cannot be verified, period. We're talking policy names with version numbers, specific procedure documents with document IDs, configuration baseline records, recent vulnerability scan reports, or training records with dates. An assessor should be able to look at your SSP, see a reference to AD GPO Baseline GPO-AC-001, and say, show me that baseline in your system right now. It- it creates a direct line from the plan to the proof.

Paul Netopski

Let's- let's look at some real-world examples to show how this actually works. Take NIST SP 800-171 Control 3.1.1, which is about limiting system access to authorized users. A bad statement just says, we use Active Directory to control user logins. A good statement, like the one in our template, says access to the Acme ERP System is restricted to authorized users provisioned in the ACME-CORP.LOCAL domain. It specifies that access control is enforced at the network boundary via a Palo Alto firewall running PAN-OS 11.x, and at the application layer via role-based access control inside Acme ERP version 6.2.

Roz the Rulemaker

Notice how it also links directly to the business processes and procedures. It states that all accounts are provisioned through a formal access request process requiring manager approval and ISSO sign-off, pointing to AC-PROC-001, section 3.1. And it addresses account lifecycle, like automatically disabling accounts not used for thirty consecutive days via GPO-AC-001, and disabling terminated employees within four business hours of HR notification per offboarding SOP HR-SOP-003. It binds the technical control to the administrative policy.

Eric Marquette

Wow. That is incredibly detailed. So, it connects the Active Directory, the firewall, the approval process, and even the HR timeline all in one place. What about when things aren't fully implemented yet? Like, how do you handle a gap without failing the assessment?

Paul Netopski

That is where you use the Partially Implemented status and tie it directly to a Plan of Action and Milestones, or a POA&M. Let's look at Control 3.3.1 for audit logging. Suppose you have logging set up on all your Windows systems, forwarding to a Splunk SIEM on-premises with a ninety-day retention. That part is fully implemented. But you have three Linux servers in engineering that aren't forwarding logs to Splunk yet. They're only retaining logs locally for thirty days.

Roz the Rulemaker

Instead of hiding that or marking the control as fully implemented, which would be a major assessment failure, you document it transparently. You mark the status as Partially Implemented. In your implementation statement, you have a section for the Implemented Portion, where you describe the Windows and Splunk setup. Then, you have an explicit Gap section where you state that Linux servers ENG-LX-01 through ENG-LX-03 are not yet forwarding logs to Splunk. And you cross-reference POA&M-0031 with a clear remediation target date, say, September 30th, 2025.

Eric Marquette

So, the POA&M acts as your official commitment to fix the gap, and the SSP shows the assessor that you're aware of it and actively managing the risk.

Paul Netopski

Exactly! Assessors actually respect that. It shows you have an active, honest security program. Now, let's look at Control 3.5.3, which is Multi-Factor Authentication. This is a great example of documenting inheritance. If you're using Microsoft Entra ID for your identities, your MFA policy enforcement is actually partially inherited. You aren't hosting the MFA servers on-premises, Microsoft is. So in your statement, you document that you partially inherit the control from your enterprise Entra ID tenant, referencing common control ENT-IA-001. But you also specify your part: you own the conditional access policy configuration, CAP-MFA-001, and you've mandated Microsoft Authenticator TOTP satisfying FIPS 140-2 validated cryptography. If you have privileged accounts, you might also specify that local console access requires a hardware YubiKey 5 FIPS series key.

Paul Netopski

Now, let's step back and look at the broader SSP document. The standard NIST template is- is honestly pretty bare-bones. To make it a truly robust compliance tool, we recommend some critical enhancements to Section 1 and Section 2. In Section 1, which covers system identification, you really need to formalize your policy review and update frequency. Align this with your organizational governance cadence. If you have quarterly executive reviews, make sure the policy review is locked into that cadence, or at a minimum, an annual requirement.

Roz the Rulemaker

And you must include visual representations of data flow and business processes. A standard text description isn't enough to satisfy rigorous administrative reviews. We want to see a Data Flow Diagram showing ports, protocols, and services, and how information moves between people, systems, and locations. But even more important is a Business Process Flow Diagram. This maps the actual lifecycle of CUI within your organization. How is CUI created? How is it processed, stored, and transmitted? What applications are involved in internal sharing, and what are the external sharing processes? You need to document automated behaviors like replication or backups. Mapping this directly to CUI lifecycle stages drastically strengthens your traceability.

Eric Marquette

So, you need to show the actual pipes and plumbing of how the data flows, not just list the servers.

Paul Netopski

Right. And that flows right into Section 2 enhancements, which focus on the system environment. You should have dedicated, structured tables. For instance, an External Systems Table. This table lists every external system, whether it is approved for handling CUI, how it connects, and crucially, how it is restricted from receiving CUI if it shouldn't have it. We also recommend documenting data classification enforcement mechanisms here, like Data Loss Prevention or Cloud Access Security Broker tools.

Roz the Rulemaker

And don't forget the Service Provider Table. When you rely on managed service providers, MSPs, or cloud services, you must explicitly document who they are, their service category, the scope of inheritance, and their defined roles and responsibilities. You have to clearly outline the inheritance model. Are you relying on a FedRAMP Moderate or High authorization under Appendix J? Or maybe FedRAMP Moderate Equivalency? You need to reference the location of the evidence, like the provider's Shared Responsibility Matrix or audit artifacts, to prove that inheritance is legally valid.

Paul Netopski

Exactly, and we do the same thing for external connections and publicly accessible websites. We need tables listing all external connections, their ports, protocols, services, encryption status, and any Interconnection Security Agreements or MOUs. For public websites, you need to document the support contacts, internal owners, authorized posters, and- and how often the content is reviewed for unauthorized data removal. This level of detail makes it incredibly easy for an assessor to see that you actually control your network boundaries.

Paul Netopski

Alright, so we've built this incredibly detailed, enhanced SSP. But the biggest danger now is what I call stale document syndrome. Organizations spend all this energy preparing for an assessment, they pass, and then they throw the SSP in a drawer and don't touch it for a year. Then, when the next audit comes around, nothing matches reality anymore.

Roz the Rulemaker

To prevent that, you must build operational upkeep directly into the document's design. This means adding a formal Change Management Table, clear update and review criteria, and an active review log. You have to define specific triggers that mandate an immediate update. It's not just an annual review. If you have an environmental change, an organizational restructure, a change in business units, or any significant technical upgrade, that must trigger a formal review of the SSP. The Change Management Table should track the reason for the update, the affected sections, the author, and the approving authority.

Eric Marquette

And how do you handle organizational changes? People leave, roles change... how do you keep the SSP from breaking when that happens?

Paul Netopski

You- you define roles, not individuals. This is a classic mistake. Don't write, John Doe is responsible for reviewing firewall logs. Because when John Doe leaves the company next month, your SSP is instantly wrong. Write, the Information System Security Officer is responsible. Use a RACI-style matrix, mapping responsibilities to functional roles like ISSO, System Administrator, or Authorizing Official. This ensures that even if you have staff turnover, your compliance framework remains perfectly intact and aligned with your actual governance structure.

Roz the Rulemaker

Finally, you must control the distribution and approval of the SSP. The document itself should carry clear sensitivity labeling in the headers and footers, such as Business Confidential or Business Intellectual Property, aligned with your internal data classification policy. The approval page needs formal sign-off from both the senior official responsible for compliance and the individual responsible for SPRS reporting. This binds executive leadership to the accuracy of the plan.

Paul Netopski

And- and when you actually present this to a CMMC Assessor, having a living, breathing document like this changes the entire dynamic of the assessment. When an assessor sees clean tables, clear RACI roles, rigorous change logs, and direct references to external evidence artifacts, they immediately know they are dealing with a mature security posture. It builds instant credibility and trust. You go from being defensive to confidently demonstrating that you actually run the program you committed to on paper.

Eric Marquette

Well, that's a perfect place to wrap. It's all about making the SSP a tool for actual security, not just a box to check. Good chatting, Paul, Roz. Talk soon.

Paul Netopski

Sounds good, Eric. Keep those boundaries secure.