SC-42(4): Notice of Collection

SC-42(4) sits in the NIST SP 800-53 System and Communications Protection (SC) family and is aimed at a simple operational outcome: people should not be surprised that you are collecting PII. In real programs, failures happen less from bad intent and more from drift. Product teams add fields, analytics SDKs start collecting identifiers, call centers begin recording, or a contractor deploys a new intake form. The organization still has a privacy notice somewhere, but it is not presented at the moment data is collected, or it does not match the actual data flows.

For a Compliance Officer, CCO, or GRC lead, the practical job is to translate “notice of collection” into repeatable requirements across channels, then make it assessable. That means: define what counts as a PII collection point, standardize how notice must be presented, embed it into SDLC and intake processes, and keep durable evidence. This page focuses on requirement-level implementation steps you can execute quickly and defend during an assessment against NIST SP 800-53 Rev. 5. ¹

Regulatory text

Excerpt (SC-42(4)): “Employ the following measures to facilitate an individual’s awareness that personally identifiable information is being collected by [the organization/system]: [organization-defined measures].” ²

Operator meaning: you must (1) define the measures you will use to notify individuals, and (2) deploy those measures so individuals have awareness when your system collects their PII. The control is intentionally parameterized: NIST expects you to choose measures appropriate to your environment and document them as an organization-defined parameter (ODP). ²

Plain-English interpretation

If your system collects PII from an individual, you need a clear, timely notice presented through the same channel where collection occurs (or immediately adjacent to it) so the individual can reasonably understand that PII is being collected. A buried privacy policy link alone is often insufficient for high-friction or non-obvious collection (for example, background mobile collection or recorded calls) because it does not reliably create awareness at the moment of collection.

Who it applies to

SC-42(4) commonly applies to:

• Federal information systems where NIST SP 800-53 is the control baseline. ¹
• Contractor systems handling federal data (including service providers) that adopt NIST SP 800-53 as a contractual requirement or security framework. ¹

Operational contexts where this becomes real work:

• Web and mobile apps with registration, profile, payments, support tickets, chat, or identity verification
• Contact centers (call recording, QA monitoring, transcription)
• Analytics/telemetry and fraud tooling collecting device identifiers or behavioral signals
• HR and recruiting portals
• Physical intake (front desk forms, visitor logs, badge issuance)
• APIs that accept PII from end users or from third parties acting on their behalf

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

Step 1: Name the control owner and “measures” (your ODP)

Decide who owns SC-42(4) day-to-day (often Privacy + Product Compliance, with Engineering implementation owners). Then write your organization-defined “measures” as enforceable standards, not aspirations. ²

A workable measures statement includes:

• Where notice must appear: “at or before submit,” “first-run prompt,” “audio notice at call start,” “signage at kiosk”
• Minimum content elements: plain statement that PII is collected; purpose at a high level; link or pointer to fuller privacy notice; where to ask questions
• Channel-specific requirements: web, mobile, IVR, paper forms, API docs

Deliverable: a one-page SC-42(4) implementation standard that engineering teams can follow and auditors can test.

Step 2: Build a PII collection-point register (completeness is the hard part)

Create an inventory of all places your organization collects PII directly from individuals. This is separate from a data map; keep it tight and testable.

Minimum columns:

• Product/system name
• Collection channel (web, iOS, Android, phone, paper, kiosk, API)
• Entry point (URL/screen/flow name/script name/form ID)
• PII elements collected (categories)
• Trigger (user types, file upload, passive collection, recorded audio)
• Required notice mechanism (template ID)
• Owner (team) and change approver
• Evidence pointer (screenshot pack, recording, config)

Practical tip: start with authentication/registration, payments, support, and telemetry SDKs. Those produce the most “silent” collection surprises in audits.

Step 3: Standardize notice patterns per channel (templates you can enforce)

Define “approved” notice implementations. Examples you can operationalize:

Web form (obvious active collection)

• Inline microcopy above the submit button: “We collect the personal information you provide on this form to [purpose]. See Privacy Notice [link].”
• If sensitive or unexpected: add a required acknowledgment checkbox.

Mobile app (first-run or feature-gated collection)

• Just-in-time notice when enabling a feature that collects PII (for example, profile completion, biometric login, background location if applicable).
• In-app privacy hub link in settings.

Call center (recording/monitoring)

• Pre-recorded IVR notice or agent script at call start: “This call may be recorded…”
• If collecting additional PII mid-call (for example, SSN), require a script line before collection.

Paper/physical intake

• Printed notice at the top of the form and signage at the intake location.
• If forms are later keyed into a system, the physical notice is still your collection notice.

API collection

• If your API is a direct individual interface (less common), include notice in the UI that invokes the API.
• If third parties collect from individuals and send you PII, contractually require the third party to provide notice; your obligation shifts to third-party risk controls, but you still need to document the model and enforce it.

Step 4: Implement and test the notices (treat as a control with QA gates)

Engineering work should produce verifiable artifacts:

• Feature flags/config showing notices enabled
• UI screenshots from production-like environments
• IVR recordings or call scripts in the CRM/telephony system
• Automated UI tests or QA test cases that assert the notice is present for each flow

Make this part of release readiness: any new field that collects PII must include a notice decision (existing notice covers it, or update needed).

Step 5: Add change control triggers (keep it from drifting)

Most SC-42(4) failures occur after launch. Add triggers to:

• Privacy review in the intake process for new forms/fields
• SDK and tag manager governance (analytics changes can introduce new identifiers)
• Call script updates
• Third party onboarding when they collect on your behalf

If you use Daydream to manage your control library, map SC-42(4) to a single control owner, a documented procedure, and recurring evidence artifacts so the program does not depend on institutional memory.

Required evidence and artifacts to retain

Auditors need proof of both design (your defined measures) and operation (they actually appear).

Retain:

• SC-42(4) implementation standard (your organization-defined measures) ²
• PII collection-point register with owners and last review date
• Screenshot pack per product/flow (dated, with environment indicated)
• Mobile screen recordings or test results showing just-in-time prompts
• Call center IVR audio file and/or agent script with version history
• Paper form templates and photos of signage placement (where applicable)
• Change tickets/PRs that show notices added/updated alongside new collection
• QA test cases and results (manual or automated)
• Third-party contract clauses requiring notice (when collection is delegated)

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me every place you collect PII from an individual. How do you know the list is complete?”
• “Where is the notice presented for this specific flow, and what does it say?”
• “How do you handle passive collection (telemetry, device IDs) where users may not realize it’s happening?”
• “How do you govern marketing tags/SDKs that can change collection without a code deploy?”
• “What happens when a third party collects PII and sends it to you?”
• “Show evidence from production, not a mock.”

Hangup: teams present a global privacy policy and assume it satisfies the control. SC-42(4) is about awareness at collection, not about having a policy somewhere. ²

Frequent implementation mistakes (and how to avoid them)

1. Inventory gap: only listing “primary” forms and missing chat, logs, call recordings, or telemetry.
   Fix: treat SDKs, tag managers, and contact center tooling as first-class collection points.

2. Notice exists but is not contextual: a footer link only.
   Fix: require just-in-time notice for non-obvious collection and for materially new categories of PII.

3. No governance for change: notices slowly become stale as fields change.
   Fix: add SDLC gates and require privacy sign-off when PII fields are added/changed.

4. No operational evidence: policy exists, but no screenshots, scripts, or test results.
   Fix: define an evidence pack per channel and collect it on a cadence aligned to releases.

5. Third party blind spot: outsourcing intake but not contractually requiring notice.
   Fix: add third-party requirements and verify their notice language during onboarding and periodic reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for SC-42(4), so this page does not cite specific case outcomes. Practically, weak notice-of-collection controls increase regulatory, contractual, and reputational risk because individuals can claim surprise or lack of transparency about PII collection. For federal and federal-adjacent environments, it also increases audit findings risk because assessors can test the presence of notices directly in systems. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign control owner and implementation owners by channel.
• Draft the SC-42(4) implementation standard with your organization-defined measures. ²
• Build the first version of the PII collection-point register for top systems and highest-risk channels (web intake, mobile onboarding, call center).
• Define evidence requirements (what screenshots, what scripts, where stored, naming convention).

By 60 days (deploy and make it testable)

• Implement notice templates across the highest-traffic collection points.
• Add QA test cases or checklists for “notice present” in each flow.
• Put change triggers into SDLC intake (new fields/forms require a notice decision).
• Collect a baseline evidence pack from production-like environments and store it in your GRC repository.

By 90 days (governance and coverage)

• Expand the register to remaining systems, including analytics/telemetry and physical intake.
• Add third-party contract language where third parties collect PII on your behalf; track these relationships in your third-party inventory.
• Run an internal spot-check: pick several collection points and verify notice presence end-to-end.
• If you use Daydream, map SC-42(4) to the control owner, procedure, and recurring evidence tasks so notice stays current across releases.

Frequently Asked Questions

Does a link to a privacy policy in the website footer satisfy SC-42(4)?

Sometimes it helps, but SC-42(4) is about an individual’s awareness at the point of collection. For non-obvious or sensitive collection, use an inline or just-in-time notice tied to the specific flow. ²

What counts as “PII being collected” for this control?

Treat any data that identifies or can be linked to an individual as in scope for notice at collection, including identifiers collected through apps, forms, calls, or other channels. Document your interpretation in the SC-42(4) measures statement so it is assessable. ²

How do we handle analytics SDKs that collect device identifiers?

Add SDKs and tag managers to the collection-point register and decide what notice is required (for example, first-run notice or a settings privacy hub). Control the change path for SDK configuration so collection does not change without review.

If a third party collects PII and sends it to us, are we still responsible for notice?

You still need a defined approach. Commonly, you require the third party to provide notice to individuals through contract terms and onboarding verification, and you document that model in your SC-42(4) procedure.

What evidence is most persuasive in an audit?

Dated screenshots or recordings from the real flow, plus the written standard that defines your notice measures and an inventory showing you did this everywhere you collect PII. Assessors also value change tickets that tie new fields to updated notice language.

How do we keep notices current without blocking product releases?

Standardize notice templates and add a lightweight SDLC gate: any new PII field requires selecting a template (or requesting an update) and attaching the screenshot/test evidence to the release ticket.

Footnotes

1. NIST SP 800-53 Rev. 5

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