SC-42: Sensor Capability and Data

To meet the sc-42: sensor capability and data requirement, you must identify sensors in your environment (physical and logical), define what sensor capabilities and data are prohibited, and enforce those prohibitions through configuration, access controls, and monitoring with audit-ready evidence. Treat this as a mix of privacy, security engineering, and asset management, not a standalone policy. ¹

Key takeaways:

• Scope and inventory come first: you cannot control “sensor capability and data” you have not identified.
• Implement enforceable technical guardrails (disable, block, restrict, log), then prove they stay in place.
• Evidence must tie prohibited sensor behaviors to specific systems, configurations, and recurring checks. ²

SC-42 sits in the System and Communications Protection (SC) family and focuses on controlling sensor capabilities and the data sensors collect, generate, or transmit. In practice, this shows up in modern environments as cameras, microphones, badge readers, building management sensors, workstation peripherals, mobile device sensors, and “always-on” collaboration or conferencing equipment. It also includes virtual sensors and telemetry features embedded in software and cloud services.

The operational challenge is simple: sensor data is easy to create and hard to contain once it flows into logs, analytics tools, third-party services, or support channels. SC-42 expects you to explicitly prohibit certain sensor capabilities and/or certain types of sensor data, then implement controls that make those prohibitions real in production. ¹

Because the provided regulatory excerpt is parameterized, your organization must define what is prohibited for your context (mission, facilities, data types, and threat model) and then show consistent enforcement across endpoints, facilities, and systems that handle federal data. This page gives requirement-level steps you can hand to system owners and assessors to get to “implemented and evidenced,” fast. ²

Regulatory text

Control excerpt (parameterized): “Prohibit {{ insert: param, sc-42_odp.01 }} ; and” ²

Operator interpretation of the excerpt:

• The control is written to require an explicit prohibition. The variable portion indicates your organization defines the prohibited sensor capability and/or prohibited sensor data for the system or environment.
• “Prohibit” is not satisfied by a memo alone. You need technical or procedural enforcement plus evidence that it works and remains in effect. ¹

What the operator must do:

1. Define prohibited sensor capabilities/data for the system boundary.
2. Implement safeguards that prevent collection, processing, or transmission of that prohibited capability/data.
3. Keep evidence that the prohibition is configured, monitored, and enforced. ²

Plain-English requirement interpretation (what SC-42 means day-to-day)

SC-42 requires you to control sensors so they cannot be used to capture or expose information your organization has decided must not be collected or transmitted in that environment. The “sensor” can be a camera, mic, location sensor, environmental sensor, badge/biometric reader, or embedded device capability; the “data” can be audio, video, images, location coordinates, biometric templates, or derived telemetry that reveals sensitive operations.

A practical reading: if a sensor could capture sensitive information, you must either disable it, restrict it, tightly control where its data goes, or prevent it from being used in prohibited ways, and prove it. ¹

Who it applies to (entity and operational context)

Entities

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data, including environments where federal information is processed, stored, or transmitted. ²

Operational contexts where SC-42 shows up

• Secure facilities, SOC/NOC floors, and restricted work areas where audio/video capture is sensitive.
• Endpoints used for regulated or federal work (laptops with webcams/mics; mobile devices with GPS).
• Conferencing rooms and smart displays with embedded microphones/cameras.
• IoT/building systems (CCTV, occupancy sensors, access control, smart assistants).
• Cloud/SaaS where “telemetry,” “diagnostics,” call recording, or screen capture features collect sensor-like data. ¹

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

Step 1: Assign ownership and define scope boundaries

• Name a control owner (often Security Engineering, Workplace/IT, or Facilities Security) and a GRC owner responsible for evidence and assessment coordination.
• Define in writing the system boundary where SC-42 applies (networks, endpoints, rooms, device classes, and SaaS instances tied to the federal workload). ¹

Deliverable: SC-42 control implementation statement with owner, in-scope assets, and enforcement approach.
Daydream tip: In Daydream, map SC-42 to a single accountable owner, link it to in-scope asset inventories, and schedule recurring evidence collection so audits do not depend on heroics. ²

Step 2: Build a sensor inventory (minimum viable, then expand)

Create an inventory that answers two questions: What sensors exist and what data can they produce.

• Endpoints: webcam, microphone, Bluetooth, Wi‑Fi scanning, GPS/location services, NFC, removable media readers, biometrics (fingerprint/face unlock).
• Facilities/IoT: CCTV, access control readers, visitor management capture devices, environmental sensors, smart TVs/voice assistants.
• Apps/SaaS: meeting recording, transcription, screenshots, “diagnostic data,” session replay, mobile SDK data capture. ¹

Deliverable: Sensor register (spreadsheet is fine) with asset ID, owner, location/system, sensor types, and current state (enabled/disabled/restricted).

Step 3: Define “prohibited” precisely (your SC-42 parameter)

Turn the parameter into enforceable statements. Write prohibitions in a way engineers can implement and auditors can test.

Example prohibition patterns (edit for your environment):

• Prohibit audio recording in restricted areas except approved security systems.
• Prohibit camera use on endpoints accessing designated federal enclaves unless explicitly approved.
• Prohibit transmission of raw video to third-party services without authorization.
• Prohibit collection of precise location by mobile apps used for federal work. ¹

Deliverable: “SC-42 Prohibited Sensor Capability and Data Standard” tied to system classifications and physical zones.

Step 4: Implement technical enforcement (prefer controls that fail closed)

Match each prohibition to at least one enforcement mechanism:

Endpoints (IT-managed)

• Device management policies to disable cameras/microphones or restrict which apps can access them.
• OS privacy controls enforced centrally (camera/mic permissions, screen recording permissions).
• Application allowlists for conferencing tools; disable local recordings where feasible.

Network / Cloud controls

• Egress restrictions so prohibited data types cannot be uploaded to unauthorized destinations (where feasible).
• SaaS admin settings: disable meeting recording/transcription by default; restrict to approved groups; require explicit enablement tickets.
• Logging and alerting on policy changes to recording/transcription settings.

Facilities / IoT

• Physical controls and signage aligned to prohibited zones (no-camera areas).
• CCTV system access restrictions and retention controls aligned to what is permitted.
• Segmentation of building management networks from federal information systems, where applicable. ¹

Deliverable: Implementation matrix mapping “Prohibition → Control → Control owner → How tested → Evidence produced.”

Step 5: Validate with repeatable tests (what an assessor will do)

Create tests that a third party assessor could reproduce:

• Attempt to enable webcam/mic on a managed endpoint in a restricted profile.
• Check SaaS admin console settings for recording/transcription/screen capture.
• Review network logs or DLP alerts for prohibited uploads.
• Inspect restricted areas for unauthorized devices and confirm exception approvals. ¹

Deliverable: SC-42 test procedure and last test results.

Step 6: Exceptions and compensating controls (keep them rare, documented, and time-bound)

You will have legitimate business exceptions (e.g., accessibility, incident response recordings, physical security cameras). For each exception:

• Document business justification, approving authority, scope, and compensating controls (restricted access, encryption, retention limits, monitoring).
• Record the technical configuration that implements the exception.
• Track exceptions to closure. ¹

Deliverable: SC-42 exception register and approvals.

Step 7: Operationalize with continuous evidence

SC-42 often fails on evidence, not intent. Put recurring evidence on rails:

• Configuration snapshots (MDM profiles, endpoint baselines, SaaS policy exports).
• Change logs for policy settings (who changed recording settings, when, and why).
• Periodic checks (spot checks of restricted rooms, endpoint compliance reports).
• Incident tickets where prohibited sensor behavior was detected and corrected. ²

Required evidence and artifacts to retain

Use this as your audit evidence checklist:

Artifact	What it proves	Owner
SC-42 implementation statement (system-specific)	Control is defined for the boundary	GRC + System Owner
Sensor register / inventory	You know where sensors exist	IT + Facilities
Prohibited capability/data standard (the SC-42 parameter)	“Prohibit” is explicit and testable	CISO/CCO delegate
Enforcement configs (MDM policies, SaaS exports, device configs)	Prohibitions are implemented	IT/SecEng
Test procedure + results	Control operates as designed	SecEng + GRC
Exception register + approvals	Deviations are governed	GRC
Monitoring/alert rules + sample alerts/tickets	You detect drift and misuse	SOC/IT

Common exam/audit questions and hangups

• “Show me what you prohibit under SC-42 for this system.” Auditors want the parameter defined, not implied. ²
• “How do you enforce it technically?” A policy without an enforcement story is a finding.
• “How do you know it stays enforced after changes?” Expect questions on drift, admin changes, and exception handling.
• “What about conferencing recordings, transcription, and support diagnostics?” These are frequent blind spots because they feel like app features, not sensors.
• “Is your inventory complete for the boundary?” If you cannot enumerate sensors, you will struggle to justify coverage. ¹

Frequent implementation mistakes (and how to avoid them)

1. Writing a prohibition that cannot be tested.
   Fix: write prohibitions in terms of concrete capabilities (recording, transmission, storage) and specific environments (device profile, room zone, tenant).

2. Treating SC-42 as “Facilities only” or “IT only.”
   Fix: run a joint working session between IT, Security Engineering, and Facilities. Sensor risk crosses both domains.

3. Allowing SaaS defaults to override policy.
   Fix: export SaaS settings, lock down who can change them, and alert on changes.

4. Exceptions with no closure path.
   Fix: require an expiry condition and periodic review tied to system changes or recertification cycles.

5. No evidence strategy.
   Fix: define recurring artifacts up front and collect them continuously (this is where Daydream helps by mapping SC-42 to owners, procedures, and recurring evidence). ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so do not treat SC-42 as “enforcement-free.” The practical risk is that uncontrolled sensor data can disclose sensitive operations, expose regulated data through recordings/transcripts/logs, and create downstream third-party risk when data lands in external processors. For federal and contractor environments, poor SC-42 implementation also creates assessment risk because auditors can test sensor behavior directly. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign SC-42 owner(s) and write the system boundary statement.
• Draft the prohibited sensor capability/data standard for in-scope environments.
• Start a minimum viable sensor register for endpoints, key rooms, and core SaaS used for meetings/support.
• Identify quick wins: disable unneeded recording/transcription features in SaaS admin consoles; restrict who can enable them. ¹

Days 31–60 (implement and test)

• Roll out endpoint policies for camera/mic permissions aligned to prohibited zones/profiles.
• Implement exception workflow and register; migrate any “informal exceptions” into the register.
• Write the SC-42 test procedure and run the first test cycle; log findings as tickets with owners and due dates. ¹

Days 61–90 (evidence, monitoring, and assessor readiness)

• Automate recurring evidence pulls (MDM compliance reports, SaaS setting exports, change logs).
• Add monitoring for drift: alerts on changes to recording/transcription settings and device compliance drops.
• Prepare an assessor packet: implementation statement, sensor register, prohibitions standard, enforcement screenshots/exports, test results, and exceptions. ²

Frequently Asked Questions

What counts as a “sensor” under SC-42?

Treat any component that captures physical or behavioral signals as a sensor: camera, microphone, location services, biometrics, badge readers, and software features like recording/transcription that generate similar data. SC-42 expects you to define what is prohibited for your environment. ¹

Does SC-42 require me to ban all cameras and microphones?

No. It requires you to prohibit specific sensor capabilities or data types you deem unacceptable, then enforce that decision. Many environments allow sensors with restrictions and documented exceptions. ¹

How do I handle conferencing platforms that offer recording and transcription?

Treat recording/transcription as sensor-data generation and storage. Disable by default, restrict who can enable it, log admin changes, and document approved use cases with compensating controls. ¹

What evidence will auditors expect for SC-42?

Auditors typically ask for the prohibition definition, the configurations that enforce it (MDM/SaaS exports), and proof the control operates (test results and monitoring/change records). Keep an exception register with approvals. ²

We rely on physical security cameras. How can we be compliant?

Document that cameras are permitted for physical security, define where they are prohibited, restrict access to footage, and record retention and access approvals as compensating controls. Tie the exception to specific devices and locations, not “blanket approval.” ¹

How do I operationalize SC-42 across many systems without drowning in spreadsheets?

Standardize the prohibited-sensors baseline by environment type (endpoint profile, room type, SaaS tenant), then map each system to the baseline and collect the same evidence artifacts on a schedule. Daydream helps by mapping SC-42 to owners, procedures, and recurring evidence so audits become a reporting exercise. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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