SC-15(3): Disabling and Removal in Secure Work Areas

SC-15(3): Disabling and Removal in Secure Work Areas requires you to disable or physically remove collaborative computing devices and applications from designated locations in designated secure work areas. To operationalize it fast, define which spaces qualify as “secure work areas,” inventory collaboration endpoints and apps allowed there, then implement technical blocks and physical removal with audit-ready evidence. ¹

Key takeaways:

• Define “secure work areas” and the specific locations inside them where collaboration tech must be disabled or removed.
• Enforce the requirement with a mix of physical controls (removal/covering) and technical controls (MDM/GPO/EDR, app allowlisting, conference-room profiles).
• Evidence wins audits: keep a location-by-location inventory, enforcement settings, exception approvals, and verification logs. ²

SC-15 is the NIST SP 800-53 control family area that covers collaborative computing devices and applications. SC-15(3) is the enhancement that matters when you have secure spaces where sensitive work happens and where ambient microphones, cameras, screen sharing, voice assistants, meeting-room PCs, or collaboration apps could capture or transmit information outside the intended boundary. The control is plain: in specified locations, inside specified secure work areas, you must disable or remove collaborative computing technology. ¹

For a Compliance Officer, CCO, or GRC lead, the operational challenge is not understanding the words; it’s turning them into a repeatable, testable rule across facilities, IT, and security operations. This page gives you requirement-level implementation guidance: how to define scope, assign ownership, deploy the technical and physical measures, handle exceptions, and retain evidence an assessor can verify quickly. Where teams fail, it is usually in scope definition (what is “secure”), asset discovery (what counts as “collaborative”), or evidence (no proof the controls are active). This is written to help you avoid those failure modes and get to “auditable” without turning the control into a facility-wide rebuild.

Target keyword: sc-15(3): disabling and removal in secure work areas requirement

Regulatory text

Control requirement (SC-15(3)): “Disable or remove collaborative computing devices and applications from [organization-defined locations] in [organization-defined secure work areas].” ¹

What the operator must do

You must make two explicit definitions and then enforce them:

1. Define the secure work areas (the rooms, suites, labs, or zones where the rule applies).
2. Define the locations within those areas (desks, conference tables, wall-mounted displays, collaboration bars, kiosks, shared workstations) where collaboration devices/apps must be disabled or removed.

Then, for any collaborative computing devices and applications present in those defined locations, you must either:

• Disable them (functionally prevented from capturing/transmitting), or
• Remove them (physically absent from the secure work area).

The practical test: an assessor should be able to walk into an in-scope secure area and verify that collaboration endpoints and apps are not active and not available in the defined locations, except where a documented exception exists. ²

Plain-English interpretation

SC-15(3) means: in secure spaces, don’t allow collaboration tech to listen, watch, record, or transmit unless you intentionally permit it. Collaboration tech includes obvious items like conference room cameras and speakerphones, and less obvious items like:

• Always-on microphones in meeting-room bars
• Built-in webcams on room PCs
• Consumer voice assistants
• Screen-sharing apps on shared workstations
• Chat/meeting clients installed on machines in a classified/restricted lab environment

You are not required to ban all collaboration everywhere. You are required to make a deliberate scope call (secure areas + locations) and implement reliable disabling/removal in that scope. ¹

Who it applies to

Entity scope

• Federal information systems and
• Contractor systems handling federal data where NIST SP 800-53 controls are part of the contractual or program baseline. ²

Operational context (where this shows up)

SC-15(3) becomes relevant when you have any of the following:

• Secure workspaces used for regulated workloads (government data, controlled research, sensitive investigations)
• Facilities with restricted areas (badge-controlled zones, closed labs, secure program spaces)
• Conference rooms used for sensitive briefings
• Shared workstations or kiosks inside restricted spaces
• Any “bring-in” pattern where employees carry laptops/phones into secure rooms and join calls

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

Step 1: Set scope definitions you can defend

Create two lists in a short standard (policy + facility annex):

• Secure Work Areas (SWA list): name, address, floor/zone, owner, access control method.
• In-scope Locations within each SWA: conference rooms A/B, briefing room podium, reception kiosk, lab bench stations, etc.

Write the decision rule for what qualifies as a SWA (examples: “rooms where regulated data is displayed,” “spaces approved for restricted programs,” “areas with controlled physical access”). Keep it consistent with your physical security program. ²

Step 2: Define what counts as “collaborative computing devices and applications”

Build a control-specific definition used for assessment:

• Devices: conference room bars, webcams, speakerphones, smart displays, meeting-room PCs, microphones, room controllers, SIP phones with conferencing, telepresence units.
• Applications: video meeting clients, screen sharing tools, persistent chat clients, remote collaboration/whiteboarding apps.

You can maintain this as a living “SC-15 technology list” owned by IT/security engineering.

Step 3: Inventory what exists in each secure work area

For each SWA, complete a simple register:

• Room/area identifier
• Device type, model, serial/MAC (where applicable)
• Installed collaboration apps (room PC image, shared workstation image)
• Network connectivity (wired/wireless, VLAN)
• Owner (Facilities/IT/AV)

This is where most teams discover shadow AV deployments. Treat conference rooms as endpoints.

Step 4: Choose the enforcement method per asset class (disable vs remove)

Use a decision matrix:

Asset type	Preferred treatment in SWA	Acceptable alternatives	Notes for auditors
Dedicated room camera/mic bar	Remove	Disable via admin console + physical lens cover + mic disconnect	Document how “disabled” is verified
Room PC	Disable collaboration apps	Replace with non-networked display device; app allowlisting	Prove apps cannot run or cannot connect
Shared workstation in lab	Remove collaboration apps	Separate “clean room” image; restrict peripherals	Keep gold image baseline evidence
Personal mobile devices	Restrict/disable in SWA policy	Device lockers; MDM geofencing controls where feasible	Enforce with signage + procedure

The control allows either disabling or removal. Removal is often easier to validate for high-sensitivity spaces. Disabling can be acceptable if it is robust and verifiable. ¹

Step 5: Implement technical controls

Pick controls that match your environment:

• MDM/UEM configuration profiles for tablets/phones used as room controllers (disable camera/mic, block app install, restrict accounts).
• GPO/MDM for Windows/macOS on room PCs and shared workstations (remove meeting clients, block executable paths, disable webcams, deny microphone access).
• Application allowlisting to prevent installation/execution of collaboration apps in SWAs.
• Network controls (VLAN segmentation, egress restrictions) to block collaboration services from SWA networks when appropriate.
• Device management for AV gear (admin console settings, firmware controls, disable cloud join features).

Tie each technical measure to the SWA and location list so you can show targeted enforcement rather than broad, informal practice.

Step 6: Implement physical controls

Physical measures matter because “secure work areas” are physical by definition:

• Remove or lock away portable collaboration devices.
• Use tamper-evident covers for cameras where removal is not feasible.
• Physically disconnect microphones for rooms that must retain displays.
• Post signage: “No collaborative devices/apps permitted” with a local contact for exceptions.
• Add a pre-brief checklist for sensitive meetings.

Step 7: Exceptions and compensating controls

You will have business pushback for hybrid meetings. Create an exceptions workflow:

• Requestor, SWA, location, business justification
• Duration and approval authority
• Compensating controls (temporary enablement only during scheduled window, local monitoring, dedicated managed device, room sweep checklist)
• Verification step when the exception expires (re-disable/re-remove)

Keep exceptions rare and time-bound. Auditors look for drift.

Step 8: Verification and ongoing monitoring

Define how you prove the control works:

• Quarterly walk-through checks by Facilities/Security for in-scope rooms
• Configuration compliance reports from MDM/GPO/AV consoles
• Change management hooks: any AV install in SWA triggers security review
• Decommission checks during room remodels and moves

Step 9: Assign ownership and make it assessable

Minimum operating model:

• Control owner: Security/GRC
• Technical owner: Endpoint engineering + AV/UC engineering
• Physical owner: Facilities/Physical Security
• Assessment support: Internal audit or compliance testing

Daydream fit: teams commonly track SWA scope, assets, exceptions, and recurring evidence in Daydream so the assessor sees a single control record with linked artifacts, rather than chasing Facilities and IT across ticketing systems.

Required evidence and artifacts to retain

Keep evidence that matches each element of the requirement:

1. Scope definitions

   • Secure work areas list with owners
   • Location list within SWAs
   • Policy/standard referencing SC-15(3) and defining “collaborative computing” ²

2. Asset inventory

   • Room-by-room device inventory
   • Room PC build standards and software inventory exports
   • Network diagrams or VLAN assignments for SWA segments (as applicable)

3. Disablement/removal proof

   • MDM/GPO configuration screenshots/exports showing camera/mic/app restrictions
   • AV admin console settings exports
   • Tickets/work orders for physical removal
   • Photos of removed devices or installed physical blocks (where your policy allows photos)

4. Exception governance

   • Approved exception records
   • Expiration and reversion verification

5. Verification and monitoring

   • Walk-through checklists and results
   • Configuration compliance reports
   • Change management records showing review/approval for installs in SWAs

Common exam/audit questions and hangups

Assessors tend to probe the edges of your definitions and the proof that disabling is real:

• “Show me your organization-defined secure work areas and the defined locations inside them.” ¹
• “What do you consider a collaborative computing device or application?”
• “How do you verify microphones/cameras are disabled, not just ‘not used’?”
• “What stops someone from reinstalling Zoom/Teams on the room PC?”
• “How do you manage exceptions for executive briefings or incident calls?”
• “Show evidence from the last verification cycle for two rooms.”

Hangup: “Secure work area” is often implicit in physical security documentation but not mapped to IT configuration scope. You need the crosswalk.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating conference rooms as ‘Facilities’ and ignoring them in endpoint security.
   Fix: Put AV/UC endpoints into your asset management and configuration compliance program.

2. Mistake: Disabling only the app icon, not the underlying capability.
   Fix: Block execution and installation, restrict device permissions (camera/mic), and restrict network access where reasonable.

3. Mistake: No defined “locations” inside secure areas.
   Fix: Specify locations down to the room level so testing is deterministic.

4. Mistake: Exceptions without reversion.
   Fix: Add an expiry date and require evidence that the device/app was re-disabled or removed.

5. Mistake: Evidence is tribal knowledge.
   Fix: Store exports, work orders, and verification checklists in a control evidence binder (Daydream can automate reminders and evidence collection).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SC-15(3) primarily as an assessment and authorization risk: failing it can drive control deficiencies, POA&Ms, delayed ATOs, or contractual nonconformance findings. The operational risk is direct: unauthorized audio/video capture, unintended remote access into secure spaces, or sensitive material exposure via conferencing tools. ²

A practical 30/60/90-day execution plan

You asked for speed. Use this as a field-ready sequence.

First 30 days (stabilize scope and stop obvious gaps)

• Name the control owner and technical/physical co-owners.
• Publish the SWA definition and initial SWA list (top-priority spaces first).
• Freeze new AV/UC installs in SWAs unless security approves.
• Run a rapid inventory sweep of SWAs: what devices/apps exist today.
• Remove the highest-risk items immediately (consumer voice assistants, unmanaged webcams/mics).

By 60 days (implement enforceable disablement)

• Implement baseline technical controls on room PCs and shared workstations in SWAs (app removal + execution controls + camera/mic restrictions).
• Put AV/UC devices under centralized management or remove them from SWAs.
• Stand up the exception workflow with a defined approver and expiration rule.
• Create the first verification checklist and perform a pilot walk-through.

By 90 days (make it auditable and repeatable)

• Expand inventory coverage to all SWAs in scope.
• Produce compliance exports (MDM/GPO/AV console) and store them as recurring evidence.
• Run a second verification cycle and document remediation actions.
• Add change-management triggers so room remodels, moves, and new installs cannot bypass SC-15(3).
• Load the control record, owners, procedures, and evidence schedule into Daydream so you can answer assessor requests from one place.

Frequently Asked Questions

What counts as a “collaborative computing device” for SC-15(3)?

Treat any device that can capture or transmit audio/video/screens for remote participation as in scope, including meeting room bars, webcams, speakerphones, and room PCs running conferencing software. Document your definition and keep it consistent across rooms. ²

Can we comply by disabling features instead of removing the device?

Yes, the requirement allows “disable or remove.” Choose disabling only if you can prove the device/app cannot record or connect in the defined locations, and you can show evidence of the settings. ¹

How do we handle executives who need hybrid meetings in secure rooms?

Use a formal exception that is time-bound, approved, and includes compensating controls plus a verified reversion step. Keep the exception record with the room’s inventory and verification logs.

Does SC-15(3) apply to personal phones brought into secure areas?

It can, if your organization-defined “collaborative devices” includes personal devices in those locations. Many programs address this with physical procedures (lockers, signage, entry checks) rather than technical enforcement.

What evidence is usually decisive in an assessment?

Assessors want three things: the SWA/location scope list, proof of disablement/removal (configuration exports or work orders), and a verification record showing you check that the state persists over time. ²

How should we document SC-15(3) in our control catalog so it stays current?

Map it to a named owner, an implementation procedure, and recurring evidence artifacts tied to your SWA inventory and exception workflow. Daydream is often used to keep that mapping and evidence collection from drifting across teams.

Footnotes

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

2. NIST SP 800-53 Rev. 5