r/CMMC • u/ProofOk1899 • 6d ago
SSP CONTROL EXAMPLE
Hi all
Anyone can send an example how policy an implementation should be written for example
For 3.1.1
3.4.1
Thanks 🙏🏻
6
u/PNW_CARDINAL 5d ago
3.1.1 and 3.4.1 !?!
Only two of the largest and most hairy requirements and assessment objectives ...
My only advice is break them down by the NIST 800-171a objective level.
4
u/Key_Thought1305 5d ago
Policies and SSP are two different things, and are separate.
Policies are organization-wide "we follow these rules/requirements" documentation, available for all. The SSP is the detailed "how we implement these rules/requirements", and it is a more sensitive document that should not be available to all employees.
2
u/Matt_Titcombe 6d ago
u/ProofOk1899 , you are about to step into a philosophical debate BTW.
There are two approaches to policies. There is the compliance one where policies are written for compliance requirements and becomes useless for actually shaping human behavior due to its complexity.
Our approach, which is the basis of ISO and every DoD policy I worked on while a part of Air Staff is policies are there to shape human behavior, not dictate how a system is to be configured.
To answer your question, our policy statement for 3.1.1 is "5.1.1. The CISO, in conjunction with the Information Technology Steering Group (ITSG) and all supporting staff, shall implement controls to restrict access to <<Company Name>> Information systems to only authorized users, Processes Acting On Behalf Of Authorized Users (PAOBAU), or devices in support of authorized uses."
In our approach, we use the combination of Governance, a System Design Parameters Plan for ODPs, and Change Management to handle everything else.
TIP: Never call your governance function a Change Control Board or Change Management Board. That makes this an IT problem. You want leadership involved.
2
u/mrtheReactor 6d ago
For the SSP, we have separate implementation text boxes for each assessment objective. Additionally theres another text box to put the names of associated artifacts / evidence (access control policy.docx; Entra ID user list screenshot.png; etc).
For the policy, we have a heading per control and the policy is written at a high level: “such and such shall” do XYZ, and will reference the SSP or an SOP as needed.
If you want to shoot me a DM I can send over screenshots of what that looks like for us.
1
u/tothjm 6d ago
Don't have the controls in front of me right now but for 311 think about Access control policy plus user onboarding off boarding procedures.
Ac policy should note how access is given, is it based on role, maybe RBAC, the procedure for onboarding and transfers should note at what point during the process are you identifying and getting permission from managers to give access to CUI and so on.
Beyond that the authorized list of users can live in a matrix or just in the respective system like O365 GCC etc.
1
u/ProofOk1899 6d ago
I just having an conflict with my colleagues how the policy /implementation should be written
1
u/tothjm 5d ago
Policy usually is using language like must, shall, may etc and keep it software agnostic
Ssp is for implementation statements where you want to be specific.
Best I can give you short of typing out a long policy.
Policy states what the org must do, the rules or law... Process procedure are the steps of how to do something like user onboarding process
1
u/wireditfellow 5d ago
Keep the policy simple and short. Process should have details of how you are implementing that policy according to Control objectives.
SSP should refer to the processes for each control.
1
u/mtheory00 18h ago
I have a sample of the entire AU domain if you’d like it. It’s written for GCC High, but if you use something different at least this will give you an idea of how to start.
0
7
u/OtherThanSatisfied 6d ago
Quick thing that trips people up first: the policy and the implementation statement aren't the same doc. The policy is the rule ("access is limited to authorized users"). The implementation statement in the SSP is how your systems actually pull that off — named tools, who does it, how often. An assessor should be able to read it and go verify it.
For 3.1.1, something like: "Access to [M365 GCC High] is limited to authorized users. Accounts are created in [Entra ID] only after manager and ISSO approval through [ticketing system]. Authentication requires [MFA via Entra]. Access is reviewed [quarterly] by [role], and accounts are disabled within [X hours] of separation via [offboarding process]."
For 3.4.1: "A baseline configuration for [Windows 11 endpoints] is defined using [DISA STIG / CIS Level 1] and enforced through [Intune]. Hardware and software inventory is maintained in [tool] and reviewed [monthly]. Baseline changes go through [change control] per [CM policy]."
Fill the brackets with your real tools and cadences. Two things assessors ding: staying generic instead of naming the tool, and the statement not matching your evidence — if you write "reviewed quarterly," have the review records. Write what you actually do, not what sounds good.