Terms / Scope and assets
Security protection asset
An asset that provides security functions for your assessment scope. It is in scope and assessed against the requirements it is relevant to.
Also called SPA, security protection assets.
Official Source Material
Security Protection Assets (SPA) means assets providing security functions or capabilities for the OSA's CMMC Assessment Scope.
Source: 32 CFR 170.4, eCFR text current as of September 17, 2026
Practitioner Guidance
What it means in practice
Anything that protects your scope is inside your scope.
The reach of this category is wider than it looks. Your identity provider, your multifactor service, and your endpoint detection tool all provide security functions for the assessed environment. So do your firewall, your vulnerability scanner, your backup platform, and the remote management tool your support provider uses. Table 3 to 170.19(c)(1) puts them in scope and assesses them against the Level 2 requirements relevant to what they provide.
The function decides the category, not where the asset runs.
A cloud service that never touches Controlled Unclassified Information is still a security protection asset when it protects the environment that does. The same is true of a tool sitting on your own rack. Ask what the asset does for the scope, not who hosts it or whether it holds the information.
Security protection data is the reason these assets carry weight.
Configuration files, log data, vulnerability results, and the credentials that grant access to the assessed environment are all security protection data. An asset holding that data can be used to reach the environment, which is why the rule brings it inside the line. AU.L2-3.3.1 covers the audit records such a platform holds. Treat a log archive with the same seriousness as a file share.
Your support provider belongs in this category.
A managed service provider with administrative reach into your assessed environment provides a security function for it. Its tooling is in scope, and its responsibilities belong in a customer responsibility matrix. Ask your provider for that document before your assessment, because writing one during the assessment goes badly.
What falls short
- An asset list that covers the protected systems but not the tools protecting them. Both are in scope and both need documenting.
- A managed service provider named in the plan with no description of what it does. The rule asks for the relationship, the services, and the split of responsibilities.
- A logging platform treated as a business tool. It holds security protection data, so it protects the scope.
Edge cases
- Your identity provider also serves the parts of the business outside the scope. It still protects the scope, so it is in, and how you separate the rest belongs in the plan.
- A tool provides a security function you do not rely on for any requirement. Say so in the plan, because the assessor works from what the plan claims.
- Your provider holds an assessment of its own. That can reduce work during your assessment, and your scope and plan still have to describe the service.
Over-engineering
- Replacing a working security tool with one marketed for compliance. The category asks you to document and secure what protects the scope.
- Building a second logging platform to keep security data apart from business data. Separating access inside one platform meets the requirement.