SI-18(3): Collection

To meet the si-18(3): collection requirement, you must design intake processes so personally identifiable information (PII) is collected directly from the individual whenever your system needs it, rather than sourced indirectly from third parties by default. Operationalize this by mapping every PII element to a direct collection channel, documenting exceptions, and retaining evidence that real workflows follow the rule. ¹

Key takeaways:

• Default to first-party collection (the individual provides the data) for each PII data element. ¹
• Treat third-party-sourced PII as an exception that needs documented justification, approvals, and compensating controls.
• Evidence matters: auditors will look for data flow maps, intake configurations, and exception records proving the control operates.

SI-18(3) is a deceptively short requirement with a real operational footprint: “Collect personally identifiable information directly from the individual.” ¹ For a CCO, GRC lead, or system owner, the work is not philosophical. It’s mechanical: identify where PII enters your environment, confirm the individual is the source, and correct workflows that pull identity data from third parties “because it’s easier.”

This requirement shows up most often in federal information systems and contractor systems handling federal data where NIST SP 800-53 is the governing control baseline. ² It also becomes a practical due diligence issue in third-party risk management because many organizations ingest PII via customer lists, data brokers, enrichment vendors, and outsourced onboarding providers.

Your goal is to make collection pathways defensible. That means: (1) knowing exactly which fields are PII, (2) proving how each field is collected, (3) documenting when you cannot collect directly and why, and (4) retaining repeatable evidence for assessors.

Regulatory text

Requirement (verbatim): “Collect personally identifiable information directly from the individual.” ¹

Operator meaning: Your system’s standard operating procedure for obtaining PII should be first-party: the individual provides their own PII through a controlled intake channel (form, portal, recorded call, signed document, verified upload). If you acquire PII from a third party (another company, a broker, an integrator, an employer, a government source, a partner), you need to treat that as a deliberate exception and manage the added integrity, transparency, and consent risks.

Plain-English interpretation

SI-18(3) is about source-of-truth and collection integrity. Direct collection:

• reduces the chance you ingest stale or incorrect data,
• improves your ability to show the individual had visibility into what you collected,
• simplifies notice, consent, and correction workflows because the intake path is known and controlled.

Direct collection does not mean you can never receive PII from third parties. It means your default design is to collect from the individual, and your governance clearly constrains when indirect collection happens.

Who it applies to

Entity scope (typical):

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually. ²

Operational scope (where you will feel this):

• Customer onboarding (identity, contact, payment, eligibility).
• HR and workforce identity (employees, contractors).
• Case management (complaints, benefits, claims).
• Security operations intake (user reports, account recovery).
• Marketing and CRM enrichment (lead lists, append services).
• Third-party administered intake (call centers, managed service desks).

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

1) Define what counts as PII in your environment

Create (or confirm) a working definition of PII aligned to your program, then list your PII data elements (name, email, phone, government identifiers, device identifiers tied to a person, etc.). SI-18(3) can’t be tested without an agreed PII inventory boundary. Tie this to your data classification standard and system boundary documentation.

Deliverable: PII data element register (by system, table/object, and field).

2) Map each PII element to its collection source and channel

For every PII element, record:

• Source: individual vs third party
• Collection channel: web form, mobile app, paper form, API, call center script, SFTP file, integration bus
• Point of collection: which application/module
• Control owner: business process owner + technical owner

A fast way to expose gaps is to produce a table that auditors can read in minutes.

Example intake mapping table (minimum viable):

PII element	System	Primary collection method	Source	Evidence pointer	Exceptions?
Email address	Customer portal	Self-service registration form	Individual	Screenshot + form config export	None
Mailing address	CRM	Entered by agent during call	Individual (verbal)	Call script + training record	If imported from partner feed, see exception EX-###

3) Make “direct collection” the default in system design

Update intake designs so the individual is the origin whenever feasible:

• Replace pre-filled values from third-party feeds with user-entered fields (or show pre-fill as “suggested” with explicit confirmation).
• Add data validation at entry (format checks, required fields) to prevent garbage-in.
• Ensure collection channels support accessibility and alternate methods when needed (for example, assisted intake via agent still counts as direct collection if the individual provides the data).

4) Build an exception path for indirect collection

You need an exception mechanism that is easy enough people will use it, and strict enough it has meaning.

Define an exception when:

• the individual cannot reasonably provide the data,
• collection must occur via an authoritative upstream party in a chain (common in federated enrollment, benefits eligibility, or employer-sponsored programs),
• law/contract requires receiving PII from another entity.

Exception record should capture:

• which PII elements are collected indirectly,
• which third party is the source,
• why direct collection is infeasible,
• what notice/consent basis is used (if applicable in your program),
• compensating controls (integrity checks, provenance tagging, dispute/correction workflow),
• approvals (privacy, security, business owner),
• review cadence and sunset condition.

5) Implement technical controls that prove provenance

Auditors will not accept “we usually collect it from the user” if system logs show bulk imports.

Minimum technical patterns:

• Provenance tagging: store metadata like source=individual vs source=third_party:<name> at field-level or record-level.
• Intake logging: keep logs that tie record creation/update to an intake channel (portal, API client, batch job).
• Import controls: restrict who can run bulk imports and require change tickets.

6) Train the operators who actually collect the data

Call center staff, HR coordinators, and partner operations teams create SI-18(3) failures through workarounds. Give them:

• a short rule: “Ask the individual first; don’t copy from old spreadsheets unless approved.”
• scripts/job aids that match the intake fields
• escalation instructions for exceptions

7) Make it assessable: map to control owner, procedure, and recurring evidence

Treat SI-18(3) as a control you can test repeatedly:

• named owner
• written procedure (collection design + exceptions)
• evidence plan (what you will export/screenshot/log each cycle)

This is the quickest way to prevent the most common risk: missing implementation evidence. ¹

Required evidence and artifacts to retain

Keep artifacts that show both design and operation:

Design evidence

• PII inventory / data element register
• Data flow diagram(s) showing intake points and sources
• Intake specifications (form designs, API schemas, call scripts)
• System configuration exports showing required fields, pre-fill behavior, and validation rules
• Procedure for “PII collection source” and exception handling

Operational evidence

• Sample intake records showing provenance/source tags
• Log extracts demonstrating record creation via direct channels
• Exception register with approvals and reviews
• Training completion records for staff performing intake
• Change tickets for modifications to intake flows and integrations

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me where PII enters the system and who provides it.”
• “Which fields come from third parties? Why?”
• “How do you prevent partner feeds from silently overwriting user-provided PII?”
• “How do you know the data is accurate and attributable to the individual?”
• “Where is the exception approval, and how often is it revisited?”

Common hangup: teams show a privacy notice and consent language, but cannot show the actual ingestion mechanism and system-of-record behavior.

Frequent implementation mistakes (and how to avoid them)

1. Assuming “direct collection” only means web forms
   Fix: treat assisted intake as direct collection when the individual provides the data verbally or via document, and capture the channel evidence (script, recording policy, agent workflow).

2. Using third-party enrichment by default in CRM
   Fix: configure enrichment as optional, confirm with the individual, and tag the provenance. If enrichment is required, document it as an exception with integrity checks.

3. No provenance metadata
   Fix: implement record-level source tagging and log retention so you can prove the origin during an assessment.

4. Exceptions live in email threads
   Fix: maintain an exception register with approvals, scope, compensating controls, and a review workflow.

5. No control ownership
   Fix: assign a single accountable owner and two supporting owners (business process + engineering). Daydream can help you keep that mapping current and produce recurring evidence packages aligned to the si-18(3): collection requirement. ¹

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for SI-18(3). Treat this as an assessment readiness and privacy risk control: indirect PII collection increases the risk of inaccurate data, complaints, and failure to meet program expectations around transparency and correction. For federal and federal-adjacent environments, poor evidence and uncontrolled third-party feeds tend to become audit findings even when intent is good.

A practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Name a control owner and publish a one-page SI-18(3) procedure tied to your intake workflows. ¹
• Produce a PII element register for the in-scope system(s).
• Build the intake mapping table for top workflows (onboarding, account changes, support tickets).
• Freeze new third-party PII feeds unless approved through an interim exception process.

Days 31–60 (close the biggest gaps)

• Remediate the highest-risk indirect collection flows (bulk imports, enrichment defaults, partner overwrites).
• Implement provenance tagging for new/updated records, or add a compensating log-based method if schema changes are hard.
• Stand up the exception register with required fields, approvers, and review workflow.
• Train intake staff and third-party operators with scripts/job aids.

Days 61–90 (make it durable and auditable)

• Expand mapping and provenance coverage to remaining systems and integrations.
• Add recurring evidence capture: monthly exports/screenshots/log samples, plus exception review minutes.
• Run a tabletop assessment: have someone independent try to answer audit questions using only your evidence pack.
• If you use Daydream for control operations, configure recurring evidence tasks and ownership dashboards so you can produce an assessor-ready packet without scrambling. ¹

Frequently Asked Questions

Does “directly from the individual” allow call-center collection?

Yes if the individual provides the information during the call and your process records the channel (for example, an agent workflow and approved script). Treat “agent typed it in” as direct collection when the data originates with the individual, not a third-party list.

What if we receive PII from another government agency or an employer?

That’s indirect collection. Document it as an exception: identify the upstream source, justify why the individual cannot provide it, and add provenance tagging and correction pathways.

Can we pre-fill fields from a third party and ask the user to confirm?

Often yes, but configure the UI so the individual actively confirms or corrects the values, and store provenance metadata that distinguishes “third-party suggested” from “individual confirmed.”

How do auditors usually test SI-18(3) in practice?

They trace a sample of records from system-of-record back to the intake channel, then ask for configuration, logs, and procedures showing the individual was the source. They also review your exception register for indirect sources.

Is SI-18(3) mainly a privacy policy exercise?

No. Policies help, but assessors will focus on data flows, system configuration, and operational evidence that proves where the PII came from. ¹

What evidence is “good enough” if we can’t change the database to add provenance fields quickly?

Use compensating evidence: integration logs showing file sender, API client identifiers, job run records, and change tickets that demonstrate controlled imports. Track this as a temporary measure and put provenance tagging on the roadmap.

Footnotes

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

2. NIST SP 800-53 Rev. 5