SA-4(7): NIAP-approved Protection Profiles

SA-4(7) requires you to restrict procurement and deployment of certain commercial security and security-enabled IT products to those evaluated against a NIAP-approved Protection Profile (PP), when a PP exists for that technology type. Operationalize it by embedding NIAP PP conformance checks into intake, architecture review, and purchasing workflows, with a documented exception path. ¹

Key takeaways:

• Build a “NIAP PP required?” decision gate into product selection for applicable technology categories. ¹
• Keep auditable proof: NIAP/CC certification artifacts, mapping to the PP, and your approval/exception records. ¹
• Treat this as a supply chain and system design control, not a policy statement; it must run every time new products are introduced. ²

SA-4(7) shows up when you build or operate federal information systems, or when you’re a contractor handling federal data, and your environment depends on commercial products with “information assurance” features (for example: crypto modules, network security appliances, identity components, secure mobility, or other security-enabling platforms). The requirement is simple to state and easy to fail in practice: if NIAP has an approved Protection Profile for a technology type, you must limit your use of those commercial products to ones successfully evaluated against that PP. ¹

For a CCO, GRC lead, or Compliance Officer, the operational challenge is defining (1) which product categories are in-scope, (2) where in your lifecycle you enforce the decision, and (3) what evidence proves you didn’t “check the box once” but actually controlled selection over time. Auditors will usually focus on whether your intake and procurement processes can prevent non-conforming products from being purchased and deployed, and whether exceptions are governed, time-bounded, and risk-accepted by the right authority. ²

This page gives requirement-level implementation guidance you can drop into your control set, purchasing gates, and due diligence playbooks.

Regulatory text

Text (excerpt): “Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and” ¹

Operator meaning: For each commercial product you procure or deploy in covered technology types, you must determine whether a NIAP-approved Protection Profile exists for that technology type. If it exists, your default position must be: only buy/use products that have successfully completed evaluation against that PP. You also need a controlled exception process for business-justified deviations, because real environments regularly hit edge cases (e.g., no evaluated product supports a required integration). ¹

Plain-English interpretation (what SA-4(7) is really asking)

• “Limit the use” means you enforce this as a gate in selection and introduction (architecture review, procurement, onboarding), not as a retroactive documentation exercise. ²
• “Commercially provided information assurance / IA-enabled” points to products that deliver or materially affect security properties (confidentiality, integrity, availability) such as encryption, authentication, boundary protection, secure configuration, and tamper resistance. Treat this as a scoping exercise you must document. ²
• “Successfully evaluated against a NIAP-approved Protection Profile” means your evidence must show evaluation against the relevant PP, not a generic security claim or a vendor whitepaper. ¹
• “If such a profile exists” creates a required check: you must be able to show you looked for a PP for the technology type and either found one (then enforced) or none existed (then documented that outcome and proceeded under your normal security requirements). ¹

Who it applies to (entity and operational context)

Entities commonly in scope

• Federal information systems operated by agencies and integrators. ²
• Contractor systems handling federal data where the program’s control baseline includes SA-4(7) or where contract language incorporates SP 800-53 controls. ²

Operational contexts where this requirement “bites”

• New product introductions: firewalls, VPN, EDR/AV, IAM components, HSM/KMS, secure gateways, mobile device management, virtual appliances, and other security-enabled infrastructure.
• Refresh cycles: replacing security appliances or migrating to a new cloud-native security service.
• M&A or inherited environments: you may inherit products that never went through your NIAP PP gate.

What you actually need to do (step-by-step)

1) Assign ownership and define the control boundary

• Control owner: typically Security Architecture or GRC, with Procurement and IT as required participants.
• Trigger events: new purchase, renewal with material scope change, major version change, new deployment pattern (e.g., moving from on-prem to cloud-managed), or onboarding a managed security service that embeds products.
• Boundary statement: list the product classes you consider “information assurance” or “IA-enabled” for your environment, and where the gate is enforced (intake form, architecture review, procurement). ²

Practical tip: Put this into a one-page “requirement control card” so the team can run it the same way every time, instead of interpreting policy language differently per project. ¹

2) Build a “NIAP PP required?” decision gate into intake and procurement

Create a short decision flow your teams must complete before purchase approval:

Decision flow (minimum viable)

1. Is the product commercial and security/security-enabled? If no, document out-of-scope rationale.
2. What is the technology type? Choose from your predefined categories (keep the list short, but explicit).
3. Does a NIAP-approved Protection Profile exist for this technology type? Record the check result. ¹
4. If yes, require evidence the product was successfully evaluated against that PP.
5. If no, proceed with standard security requirements, but retain proof that no PP existed at time of selection. ¹

Where to implement the gate:

• Architecture Review Board checklist
• Purchase requisition workflow (hard stop without evidence)
• Third-party risk onboarding workflow (if the “product” is delivered as a service)

3) Define acceptable evidence rules (what “successfully evaluated” means in your program)

Set your program’s evidence acceptance criteria so reviewers don’t improvise:

• Evidence must identify the Protection Profile and show the product’s evaluation against it. ¹
• Evidence must be tied to the specific product/version/configuration you’re buying where possible (at minimum, record what the vendor claims is covered by evaluation and how that maps to your deployment).
• If the vendor can’t provide clear evaluation artifacts, treat it as not compliant until proven otherwise.

4) Stand up a formal exception process (because you will need it)

SA-4(7) doesn’t eliminate business constraints. It forces governance.

Minimum exception packet:

• Business justification (why evaluated products don’t meet requirements)
• Security impact analysis (what security property is at risk)
• Compensating controls (configuration hardening, monitoring, segmentation, cryptographic boundary adjustments)
• Approver (risk owner) and expiry/review date (your choice, but make it time-bounded)
• Plan to migrate to a PP-evaluated product when feasible ²

5) Operationalize recurring control health checks

You need a way to show the control keeps working over time:

• Periodic sampling of recent purchases/deployments for in-scope categories
• Verification that evidence bundles exist and exceptions are current
• Remediation tracking to closure when gaps are found ¹

Where Daydream fits naturally: teams often fail on repeatability and evidence completeness. Daydream can standardize the “control card,” attach required evidence bundles per intake cycle, and track exceptions and remediation items to validated closure so you can answer audits quickly. ¹

Required evidence and artifacts to retain

Keep evidence aligned to the lifecycle event (selection, purchase, renewal, deployment). A practical evidence bundle looks like this:

Artifact	What it proves	Owner
Product intake record (ticket/form) with technology type and NIAP PP check	You performed the “PP exists?” check and categorized the product	Requestor + GRC
NIAP/PP evaluation documentation from the third party	Product was successfully evaluated against a NIAP-approved PP	Procurement / Security
Architecture/security review approval	The gate was enforced before deployment	Security Architecture
Exception request (if any) + risk acceptance + expiry	Deviations are governed and time-bounded	Risk owner / CISO / Authorizing Official
Procurement approval/PO linkage	The approved product is the one purchased	Procurement
Control health-check results + remediation tickets	Ongoing operation, not one-time compliance	GRC

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

1. Show me your process: Where is the enforced gate that prevents non-evaluated products from being bought? ²
2. Show me a sample: Provide recent in-scope purchases and their NIAP PP evaluation evidence. ¹
3. How do you decide “PP exists”? What’s your documented method and who performs it? ¹
4. What about inherited tools already deployed? What’s your plan to validate and remediate gaps?
5. How are exceptions controlled? Who can accept risk, and how do exceptions expire and get re-reviewed? ²

Hangups that slow assessments:

• Evidence is scattered across email threads and vendor portals.
• Teams confuse “compliance certifications” generally with NIAP PP evaluation specifically.
• The organization can’t explain scoping and ends up debating what “IA-enabled” means during the audit.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-4(7) as a policy statement only.
   Fix: Implement a hard workflow gate in intake/procurement. If the tool can be purchased without the PP check, the control is not operating. ²

2. Mistake: No defined technology-type taxonomy.
   Fix: Maintain a short list of in-scope categories and map each purchase to one category. This prevents ad hoc scoping fights.

3. Mistake: Accepting vendor marketing claims as “evaluation.”
   Fix: Require evaluation artifacts tied to the relevant NIAP-approved PP and record them in your evidence system. ¹

4. Mistake: Exceptions with no expiry or remediation plan.
   Fix: Make exceptions time-bounded and track migration or compensating controls with accountable owners. ²

5. Mistake: No back-check of existing deployments.
   Fix: Run an inventory-based sweep of in-scope products and close gaps with replacement plans or approved exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions. ²

Operationally, the risk is straightforward: selecting security and security-enabled products without standardized evaluation increases the chance you deploy technology with unverified security claims, weak assurance boundaries, or misaligned security properties for federal system expectations. SA-4(7) reduces that risk by forcing evidence-based product selection when NIAP PPs exist for the technology type. ¹

A practical 30/60/90-day execution plan

First 30 days (stand up the gate)

• Name the control owner and approvers; publish a one-page control card (objective, scope, triggers, steps, exceptions). ¹
• Define your in-scope technology categories for “IA/IA-enabled” products, tied to procurement and architecture review.
• Add the NIAP PP decision fields to your intake/procurement workflow and make them required for in-scope categories.
• Define evidence acceptance rules and where evidence must be stored.

Days 31–60 (operate it on real purchases)

• Run the workflow on active purchase requests and renewals; stop or remediate requests lacking PP evidence when a PP exists. ¹
• Launch the exception process with risk acceptance and expiry requirements.
• Train procurement, security architects, and third-party risk reviewers on “what counts” as evidence.

Days 61–90 (prove ongoing operation)

• Do a control health check: sample recent in-scope purchases and verify end-to-end evidence completeness. ¹
• Inventory existing in-scope security products; identify gaps against your NIAP PP requirement and open remediation or exception tickets.
• Produce an audit-ready package: process description, sample transactions, evidence bundles, and exception register.

Frequently Asked Questions

Does SA-4(7) apply to SaaS providers or only hardware/software appliances?

It applies to “commercially provided information assurance and information assurance-enabled IT products,” so it can apply to embedded products inside a service if those products are part of your security posture and selection decision. Your safest approach is to scope by technology type and enforce the PP check wherever you select security-enabling capabilities. ²

What if no NIAP-approved Protection Profile exists for the technology type?

Document that you checked and found no applicable PP at the time of selection, then proceed under your normal security requirements and risk assessment process. Keep that “no PP exists” record with the procurement evidence bundle. ¹

What evidence should we ask a third party to provide?

Ask for documentation that the product was successfully evaluated against a NIAP-approved Protection Profile for that technology type, and file it with the specific purchase/renewal record. If the third party can’t provide clear evaluation evidence, route the request through your exception process. ¹

Is a general Common Criteria claim enough to satisfy SA-4(7)?

SA-4(7) is specific: it requires successful evaluation against a NIAP-approved Protection Profile when one exists for the technology type. Your review should confirm the PP linkage, not just a broad claim of evaluation. ¹

How do we handle products already deployed that weren’t checked against NIAP PPs?

Treat them as inherited risk: inventory in-scope products, determine whether a PP exists for each technology type, and then either collect evaluation evidence, replace the product, or approve a time-bounded exception with compensating controls. ²

Who should be the risk owner for exceptions?

Assign exception approval to the role accountable for system risk (often the system owner or authorizing official in federal contexts) and require documented acceptance with an expiry and review trigger. Keep the approval record with the exception packet for audit. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5