03.13.12: Collaborative Computing Devices and Applications

To meet the 03.13.12: collaborative computing devices and applications requirement, you must control how collaboration tools (for example, conferencing, screen sharing, remote assistance, shared whiteboards, and chat) are configured and used so they don’t expose CUI through unauthorized audio/video capture, uncontrolled recording, or unintended sharing. Operationalize it by standardizing approved tools, hardening configurations, restricting features, and retaining proof of enforcement. ¹

Key takeaways:

• Define and enforce an “approved collaboration stack” with secure defaults for CUI work. ¹
• Disable or tightly govern high-risk features (recording, anonymous join, external sharing, uncontrolled remote control) based on CUI workflows. ¹
• Keep audit-ready evidence: configurations, access rules, exceptions, and operational logs that show controls actually run. ¹

03.13.12 is easy to misread as “turn off Zoom.” That approach fails in practice because collaboration tooling is deeply embedded in engineering, program delivery, and support operations, and many teams must collaborate with third parties. What assessors look for is simpler: you identified the collaborative computing devices and applications in scope for CUI, you set guardrails that prevent accidental exposure, and you can prove those guardrails are consistently enforced. ¹

This requirement sits in the security assessment mindset of NIST SP 800-171: assume users will screen-share the wrong window, meetings will include the wrong participant, and recordings will land in unmanaged storage if you allow default behaviors. Your job is to reduce that risk through design: limit which tools are allowed, reduce feature surface area, and make “safe collaboration for CUI” the default path. ¹

Below is requirement-level implementation guidance you can hand to IT, Security Engineering, and program leadership to standardize collaboration controls, close the common audit gaps, and build a clean evidence trail for assessments. ¹

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.13.12 (Collaborative Computing Devices and Applications).” ¹

Operator interpretation: You must manage collaboration endpoints and tools so they don’t become a side channel for CUI loss. In practice, that means: (1) identify which collaboration apps/devices are permitted for CUI-related work, (2) configure them to prevent unauthorized access, recording, and sharing, (3) restrict external participation and data movement paths, and (4) retain evidence that these controls are implemented and monitored. ¹

Plain-English interpretation of the requirement

The 03.13.12: collaborative computing devices and applications requirement expects you to treat collaboration as part of your security boundary, not “user convenience tooling.” Collaboration features that commonly create exposure include:

• Recording (local or cloud) and transcription
• Screen/application sharing and remote control
• File transfer inside chat/meetings
• External participant access (anonymous join, guest accounts)
• Add-ins/integrations that export data to third-party storage

Your goal is to ensure CUI is only shared with authorized participants, through approved tools, with controlled retention and storage locations, and with reliable logs for review. ¹

Who it applies to

Entities:

• Federal contractors and any nonfederal organization processing, storing, or transmitting CUI in nonfederal systems. ¹

Operational contexts in scope:

• Video conferencing used for program reviews where CUI may be presented
• Screen-sharing during engineering support, remote troubleshooting, or remote assistance
• Persistent chat channels used for coordination and incident response
• Shared digital whiteboards used for design discussions
• Conference room devices (cameras, mics, smart displays) and “always-on” assistants in CUI workspaces
• Third-party collaboration with customers, subcontractors, and suppliers where CUI is discussed or displayed

If CUI can appear in the meeting, chat, transcript, recording, shared board, or file transfer, your collaboration controls are in scope. ¹

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

1) Build an inventory of collaborative computing tools and devices (scoped to CUI workflows)

Create a scoped list of:

• Collaboration applications (conferencing, chat, whiteboard, remote support)
• Collaboration devices (conference room endpoints, webcams, microphones, smart displays)
• Key integrations (calendar, storage, transcription/AI assistants, ticketing)

Tie each item to the CUI workflow it supports (program review, support calls, design sessions). This becomes your “collaboration boundary map” for assessment conversations. ¹

2) Define an “approved collaboration stack” and block or restrict everything else

Publish a standard that answers:

• Which tools are approved for CUI discussions and screen sharing
• Which tools are allowed only for non-CUI internal use
• Which tools are prohibited (or require explicit exception approval)

Enforce it with technical controls where possible (SSO allowlists, CASB/SSE policies, endpoint application control, mobile device management restrictions). Document exceptions with compensating controls. ¹

3) Set secure configuration baselines (and apply them consistently)

For each approved tool, define baseline settings that reduce CUI exposure. Typical baseline decisions you need to make and document:

• Meeting access: require authentication; restrict anonymous join; restrict who can bypass lobby/waiting room
• Sharing controls: default to single-application sharing; restrict who can share; restrict remote control
• Recording controls: disable by default for CUI meetings or restrict to designated roles with justification; enforce approved storage locations if recording is required
• External collaboration: define when guests are allowed; require domain allowlists; restrict guest chat/file transfer where feasible
• Data retention: align chat/transcript retention to policy; ensure deletion and legal hold processes are understood
• Logging: enable audit logs for meeting events, participant join/leave, sharing, recording start/stop, file transfers (where supported)

Write these as implementable config statements, not policy prose. Example: “Only meeting organizers in the ‘CUI-Meeting-Hosts’ group may initiate recordings; recordings save only to approved tenant storage.” ¹

4) Implement role-based access and workflow guardrails

Add operational guardrails that make safe behavior the default:

• Create standard meeting templates for CUI sessions (restricted join, disabled recording, controlled sharing)
• Use group-based entitlements for higher-risk actions (recording, external invites, adding integrations)
• Require approved channels/teams/spaces for CUI projects; prohibit ad-hoc external group creation without review

If your organization routinely collaborates with third parties, document the onboarding pattern: how external identities are vetted, what conditions apply (MFA, terms, restricted access), and who approves. ¹

5) Control collaboration in physical spaces (devices, rooms, and “always-on” risk)

Conference rooms often fail audits because they’re unmanaged. Minimum expectations:

• Maintain an inventory of collaboration room devices in CUI areas
• Ensure room devices are managed (patching, configuration control, admin access)
• Disable consumer voice assistants or “always listening” features in CUI spaces if they create uncontrolled audio capture risk
• Post room-level usage rules for CUI meetings (for example, “no personal devices recording,” “verify participants,” “no public meeting links”)

If you must allow conference room participation for CUI meetings, treat the room endpoint like any other managed asset with enforced configuration. ¹

6) Monitor, review, and prove ongoing operation

Assessors will ask for proof beyond “we configured it once.” Establish:

• A recurring configuration review (baseline drift checks)
• Periodic audit-log review for risky events (recording enabled, external participants, file transfer events)
• An exception register with expiry and owner
• Incident response playbooks for collaboration-related exposure (mis-share, wrong attendee, unauthorized recording)

Daydream commonly fits here as the system of record for mapping 03.13.12 to your policy/control statements and scheduling recurring evidence pulls (config exports, admin settings screenshots, audit log samples, and exception approvals) so you’re not rebuilding proof during assessment windows. ¹

Required evidence and artifacts to retain

Keep evidence that answers “what is allowed,” “how it’s enforced,” and “how you know it stayed enforced”:

Governance and scoping

• Collaboration tooling inventory (apps/devices/integrations) tied to CUI workflows
• Approved collaboration stack standard (allowed / restricted / prohibited)
• CUI collaboration procedures (meeting setup, external participation, recording rules)

Technical configuration proof

• Admin configuration exports or screenshots for each approved tool (key settings highlighted)
• Group/role definitions for privileged collaboration actions (recording, external invites, remote control)
• Meeting templates and policy objects (where supported)
• Device management proof for room endpoints (MDM/UEM enrollment, configuration profiles)

Operational proof

• Audit logs samples showing enforcement (blocked anonymous join, recording restrictions, external access controls)
• Periodic configuration review records (change tickets, drift reports)
• Exception register (approver, scope, compensating controls, expiry)
• Training/communications targeted to CUI collaboration behaviors

All artifacts should be dated, attributable (owner/system), and reproducible. ¹

Common exam/audit questions and hangups

Auditors and assessors tend to press on these points:

• “Which collaboration tools are approved for CUI, and how do you block the rest?” ¹
• “Show me the exact settings that prevent anonymous join, uncontrolled recording, and unrestricted screen sharing.” ¹
• “How do you handle external participants? Who approves and how do you verify identity?” ¹
• “Where do recordings/transcripts go, what is retention, and who can access them?” ¹
• “How do you manage conference rooms and shared devices in CUI areas?” ¹
• “Prove ongoing operation: what logs do you review and where is the evidence?” ¹

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. Teams write “don’t record CUI meetings” but leave recording enabled tenant-wide. Fix: enforce by configuration and group entitlements; keep exports as evidence. ¹

2. Allowing external guests without a model. Ad-hoc invites create uncontrolled access paths. Fix: require approved external identity onboarding, domain allowlists, and meeting templates for external sessions. ¹

3. Ignoring room systems. Conference rooms are often unmanaged and shared. Fix: inventory them, manage them, and document room usage rules for CUI. ¹

4. Recording/transcripts stored in the wrong place. Even compliant meetings can generate noncompliant artifacts. Fix: restrict who can record, require approved storage, and align retention and access controls to CUI rules. ¹

5. No recurring evidence. You pass once, then drift. Fix: schedule periodic configuration reviews and log sampling; store evidence in a predictable folder structure or a GRC system with reminders. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this specific requirement in the source catalog. ¹

Operationally, the risk is straightforward: collaboration tools can create new copies of CUI (recordings, transcripts, shared boards) and can disclose CUI to unauthorized parties (wrong attendee, public links, uncontrolled sharing). That combination drives reporting, contractual, and reputational impact even when your core systems are well controlled. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop obvious bleed)

• Identify approved collaboration tools for CUI and publish an interim standard. ¹
• Turn on and validate audit logging for your primary collaboration platforms. ¹
• Implement high-impact settings: authenticated join, waiting room/lobby controls, restricted sharing/remote control, and default recording restrictions for CUI-host groups. ¹
• Create an exception process for business-critical edge cases (customer-mandated platform, accessibility needs). ¹

Days 31–60 (standardize and harden)

• Complete the collaboration inventory including room devices and key integrations. ¹
• Build CUI meeting templates and external collaboration patterns (guest vetting, allowlists, approvals). ¹
• Document retention and storage rules for recordings/transcripts, and validate access controls with test accounts. ¹
• Start recurring evidence collection (config exports and a small set of log samples). ¹

Days 61–90 (prove operation and close audit gaps)

• Implement drift checks (periodic baseline review with change control references). ¹
• Run a tabletop for a collaboration exposure scenario (mis-share or unauthorized recording) and update playbooks. ¹
• Validate third-party collaboration controls with real projects: confirm external participant restrictions, file transfer settings, and meeting templates are used. ¹
• Package evidence for assessment: scope, configurations, exceptions, and operational proof. ¹

Frequently Asked Questions

Does 03.13.12 require us to ban all collaboration tools for CUI?

No. It requires you to control collaborative computing devices and applications so they don’t expose CUI through uncontrolled sharing, recording, or access paths. Standardize approved tools and lock down risky features. ¹

Are video conference recordings automatically out of scope if we “don’t record CUI” by policy?

Policy language is not enough by itself. Assessors typically expect technical enforcement or strong compensating controls plus evidence that recordings and transcripts are restricted and monitored. ¹

How should we handle customer-required platforms that aren’t our standard tool?

Treat it as an exception with documented risk acceptance and compensating controls, such as limiting what can be shared, restricting attendees, and avoiding creation of persistent artifacts like recordings. Track the exception owner and expiry. ¹

Do conference room devices matter for this requirement?

Yes if they are used for CUI collaboration. Inventory them, ensure they are managed, and control features that could capture or store CUI without governance. ¹

What evidence is most persuasive in an assessment for 03.13.12?

Configuration baselines with exports/screenshots, group-based permissions for risky features, audit logs showing enforcement events, and a clean exception register. Evidence should show both design and ongoing operation. ¹

Where does Daydream fit without turning this into a tool project?

Use Daydream as the control-to-evidence backbone: map 03.13.12 to your policy statements, assign owners, schedule recurring evidence pulls, and store exceptions and review records so audits are a retrieval exercise, not a scramble. ¹

Footnotes

1. NIST SP 800-171 Rev. 3