SC-15(4): Explicitly Indicate Current Participants

SC-15(4) requires you to show every user in a communication session exactly who is currently participating, in a way that is unambiguous and kept up to date. Operationalize it by defining which “sessions” are in scope, implementing participant indicators in your conferencing/chat/telephony tools, and retaining evidence that the indicator works and is reviewed. ¹

Key takeaways:

• Scope the requirement to real systems and session types (meetings, calls, chats, shared workspaces) and document where participant display must occur.
• Configure tools so participant identity is explicit, current, and visible to all session participants, including join/leave updates.
• Keep repeatable evidence: configurations, screenshots, test results, and periodic control checks mapped to an owner.

The sc-15(4): explicitly indicate current participants requirement is a practical control: if people cannot clearly see who is in a session, they can share sensitive information with an unintended party or miss that an unauthorized party joined. That risk shows up in day-to-day operations, not just in “high security” environments. Think video conferences where dial-in callers appear as “Unknown,” persistent chat channels where guests are not clearly labeled, or bridge lines where participants join without any roster.

SC-15(4) is an enhancement to SC-15 (Collaborative Computing Devices). In operator terms, it pushes you past “we use approved collaboration tools” into “the tool experience makes the participant list explicit and reliable.” You will need to make design decisions (what counts as “explicit”), configuration decisions (how each platform displays identity), and governance decisions (who owns it, how you test it, and what evidence you keep for assessors).

This page gives requirement-level implementation guidance you can execute quickly: scoping, minimum viable technical settings, evidence to collect, and the audit questions you should pre-answer.

Regulatory text

Requirement (verbatim): “Provide an explicit indication of current participants in {{ insert: param, sc-15.04_odp }}.” ¹

Operator meaning: For every in-scope collaborative session, users must be able to see a clear, current list (or equivalent explicit indicator) of who is participating right now. “Explicit” means the identity is presented in a way a reasonable user can interpret without extra steps or ambiguity. “Current” means the indicator updates when participants join, leave, or change identity state (for example, anonymous dial-in becomes authenticated).

Because the control text uses an organization-defined parameter (the “ODP”), you must define what session types and technologies are in scope and what “explicit indication” looks like for your environment. Document that definition and enforce it consistently. ¹

Plain-English interpretation (what the requirement expects)

You meet SC-15(4) when:

• A participant can reliably determine who else is present in the session before sharing sensitive information.
• The participant list is not misleading (for example, “Guest” with no differentiator for multiple guests, or “iPhone” with no user association when the session contains regulated data).
• The roster is available to all participants (or at least to those who need it to make a disclosure decision), not only to hosts or admins.
• The roster stays accurate as the session changes (join/leave, transfer, merge, reconnection, anonymous-to-authenticated transitions).

Who it applies to (entity and operational context)

This requirement typically applies to:

• Federal information systems that adopt NIST SP 800-53 Rev. 5 controls. ²
• Contractor systems handling federal data where 800-53 controls are flowed down through contracts, ATO requirements, or agency security requirements. ²

Operationally, it applies anywhere you have collaborative or multi-party communications, including:

• Video conferencing and audio bridge lines
• Enterprise chat and channels (including external/guest access)
• Virtual “war rooms” or incident collaboration spaces
• Shared interactive sessions (screen sharing, remote assistance) where multiple parties are effectively “in the room”
• Any collaboration feature embedded in business systems (for example, in-ticket chat, customer collaboration portals) if those sessions can include sensitive information

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

Step 1: Define your scoping statement (your ODP)

Write a short scoping statement that answers:

1. In-scope session types: video meetings, voice calls, chat channels, shared workspaces, remote support sessions.
2. In-scope platforms: list the sanctioned tools and any approved exceptions.
3. Identity rule: what identity attributes must be shown (display name plus a unique attribute when needed, such as email/UPN, organization, or verified phone label).
4. Ambiguity rule: what is unacceptable (duplicate names without disambiguation, “Unknown,” “Guest” without differentiation, hidden participants).
5. User visibility rule: who must be able to see the roster (all participants by default, with any justified exceptions).

Keep it short and testable. This becomes your assessment anchor. ¹

Step 2: Inventory collaborative entry points and risky patterns

Create a collaboration inventory that includes:

• Platform name, owning team, and tenant/admin boundary
• External access modes (guest accounts, federation, dial-in, PSTN, anonymous join links)
• Participant display behavior for each mode
• Data sensitivity context (where regulated or controlled data is discussed)

Common high-risk patterns to flag during inventory:

• Dial-in users appear without a unique identity.
• Guest users show generic labels that do not distinguish identity.
• “Lobby” or waiting room participants are not visible to everyone who is already in the session.
• Breakout rooms or side sessions have different roster visibility rules than the main session.

Step 3: Configure each platform to make participation explicit

For each approved platform, configure controls so the participant roster is explicit and current. Your exact settings will be tool-specific, but your design requirements should be consistent:

Minimum configuration expectations

• Require authenticated join for internal sessions that handle sensitive data, or clearly label unauthenticated participants.
• Disable anonymous join where feasible; if allowed, require the host to acknowledge and the tool to clearly label the participant.
• Enable participant roster visibility to participants (not only the organizer), unless there is a documented exception.
• Turn on join/leave notifications or ensure the roster updates are obvious.
• External participant labeling: visually distinguish external domains/tenants/guest accounts.
• Phone participation: require unique dial-in identification where feasible (assigned dial-in profiles) or force the host to verify and rename participants to a known identity.

If a platform cannot support an explicit roster for a given join method, treat that join method as not approved for sensitive sessions and document the restriction.

Step 4: Write a short operational procedure users can follow

Controls fail when users do not know what “good” looks like in the moment. Publish a one-page procedure:

• How to open the participant panel and verify attendees
• What to do if “Unknown/Guest/Caller” appears
• When to pause and re-verify (after someone joins, after a transfer, at the start of sensitive agenda items)
• How to remove or report suspicious participants
• How to document verification for high-risk sessions (for example, regulated data discussions or incident response calls)

Tie this procedure to your acceptable use and meeting security standards so it is enforceable.

Step 5: Assign a control owner and build recurring checks

You need one accountable owner (often Collaboration/UC Engineering, with GRC oversight). The owner should:

• Review platform settings after major releases or tenant changes
• Run periodic test sessions that include guest join and dial-in join
• Track exceptions (business need) and compensating controls (manual roll call, restricted meeting types)

A lightweight way to keep this organized is to track SC-15(4) in your GRC system with:

• Owner
• In-scope platforms
• Implementation notes per platform
• Evidence cadence and review dates

Daydream can help by mapping SC-15(4) to an owner, a written implementation procedure, and recurring evidence artifacts so you are assessment-ready without rebuilding the same package each cycle. ¹

Required evidence and artifacts to retain

Assessors usually want to see both design and operating effectiveness. Keep evidence that is tool-specific, time-stamped, and repeatable.

Design evidence

• SC-15(4) scoping statement (your ODP definition) and applicability rationale ¹
• Collaboration platform standards (meeting configuration baseline, guest access baseline)
• Screenshots or exported configuration showing:
  • Roster visibility settings
  • Guest labeling / external user indicators
  • Anonymous join and dial-in policies
• Exception register: platform gaps, approved exceptions, compensating controls, expiration dates

Operating evidence

• Test scripts and test results (example: create a meeting, join as internal authenticated, join as guest, join by phone; verify roster clarity)
• Dated screenshots from test meetings showing the participant list and labels
• Change tickets or audit logs showing settings were reviewed/updated
• Training/communications artifact: a one-page “verify participants” procedure and proof of distribution (LMS assignment record or internal comms post)

Common exam/audit questions and hangups

Expect these questions, and prepare the artifacts above to answer them quickly:

1. “What sessions are in scope for SC-15(4)?”
   Hangup: teams answer “Teams/Zoom” but miss embedded collaboration in other systems.

2. “Show me how a user can tell who is in the meeting right now.”
   Hangup: admins can see more than regular users; ensure the participant view is explicit for typical attendees.

3. “How do you handle dial-in participants?”
   Hangup: dial-in appears as a phone number or “Caller.” Have a defined verification and renaming procedure.

4. “How do you distinguish external participants?”
   Hangup: guests appear identical to internal users; you need labeling or a policy to restrict external joins for sensitive sessions.

5. “What evidence shows this control is operating?”
   Hangup: policy-only answers. Provide dated tests, screenshots, and review records.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “participant list exists” as compliant.
Fix: define “explicit” with ambiguity rules (no generic “Guest,” require disambiguation) and test from a normal user account.

Mistake 2: Ignoring join paths outside the happy path.
Fix: test guest, federated, anonymous (if enabled), and dial-in join. Document which are disallowed for sensitive sessions.

Mistake 3: Relying on manual roll call with no triggers.
Fix: allow manual verification as a compensating control only with a defined trigger (high-sensitivity sessions, unknown participant label present) and a documented procedure.

Mistake 4: No ownership, no recurring check.
Fix: assign a named owner and schedule periodic verification tied to platform change management. Track it like any other security baseline.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control enhancement, so treat it primarily as an assessment-readiness and incident-prevention requirement rather than a case-driven item.

Risk-wise, SC-15(4) reduces:

• Accidental disclosure to the wrong participant (misrouted invite links, guests, wrong dial-in)
• Social engineering via silent or misrepresented participation
• Confusion during incident response or privileged sessions where knowing who is present is part of control discipline

For regulated environments, inability to identify participants can also complicate incident scoping and internal investigations because you cannot credibly reconstruct who had access to sensitive discussion in real time.

A practical 30/60/90-day execution plan

First 30 days (baseline and quick wins)

• Name a control owner and back-up owner.
• Publish your SC-15(4) scope statement (sessions, platforms, identity display rules). ¹
• Inventory collaboration platforms and join methods, including external access and dial-in.
• Lock in obvious settings: enable roster visibility, enable join/leave cues where supported, tighten anonymous join where feasible.
• Draft the one-page “verify participants” user procedure.

By 60 days (platform hardening and evidence)

• Implement per-platform baselines for participant identification and external labeling.
• Create and run a repeatable test script across each platform and join path; store dated results.
• Stand up an exception register and remediation plan for gaps.
• Train high-risk user groups (executives, finance, incident responders, HR, procurement) on the verification procedure.

By 90 days (operationalize and make it audit-ready)

• Embed SC-15(4) checks into change management for collaboration tools.
• Schedule recurring control checks (configuration review plus functional test).
• Validate evidence completeness: scope statement, configs, test results, exceptions, and training artifacts.
• If you use Daydream, map SC-15(4) to the owner, procedure, and recurring evidence tasks so the control stays current as platforms and settings change. ¹

Frequently Asked Questions

What counts as an “explicit indication” of participants for SC-15(4)?

A participant roster or equivalent indicator that clearly shows who is present, without ambiguity. If your tool displays multiple “Guest” entries or “Unknown Caller,” it is not explicit unless you have a defined method to identify and relabel them. ¹

Do we have to show the participant list to every attendee?

The control text does not specify role-based visibility, but assessors will expect the indication to be available to users who need to make disclosure decisions. If you restrict rosters to hosts, document the rationale and apply compensating controls for sessions with sensitive content. ¹

How do we handle phone dial-in users who appear as “Caller”?

Set a procedure: the host verifies identity, renames the participant to a known name, or removes them if identity cannot be verified. If your environment cannot support reliable identification for sensitive sessions, restrict dial-in for those sessions. ¹

Are guest users allowed if we can see them in the roster?

Guest access can be compatible if guests are clearly labeled and distinguishable from internal users and if the roster stays current. Many programs still restrict guests for sensitive sessions; if you do, document the restriction in your scoping statement and platform baselines. ¹

Does SC-15(4) apply to persistent chat channels and shared workspaces?

If the channel functions as a collaborative session where sensitive information may be discussed, treat it as in scope. Your scoping statement should explicitly include or exclude these collaboration modes and define what “current participants” means for them (for example, active members vs. currently online). ¹

What’s the minimum evidence to satisfy an assessor?

Keep a written scope/ODP definition, screenshots or exports of key settings, and dated functional tests showing participant identity visibility for each join method you allow. Add an owner assignment and a record of periodic review to show the control keeps working over time. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5