CMMC Level 2 Practice 3.13.14: Control and monitor the use of Voice over Internet Protocol (VoIP) technologies

VoIP is often treated as “just phones,” but for CMMC Level 2 it is another networked communications stack with identities, endpoints, management planes, encryption settings, and third-party dependencies. If users can place calls, forward voicemails to email, record calls, or connect softphones from unmanaged devices, you can end up with CUI discussed, stored, or transmitted outside your assessed environment without visibility.

The intent of cmmc level 2 practice 3.13.14: control and monitor the use of voice over internet protocol (voip) technologies requirement is straightforward: you must (1) decide what VoIP is permitted in your environment, (2) enforce that decision with technical controls and configuration, and (3) monitor for drift, misuse, and anomalies with evidence you can show an assessor. This page translates the requirement into an implementable control set: what to lock down, what to log, what to review, and what artifacts to retain so your team can pass an assessment and reduce communications-channel risk in day-to-day operations. (NIST SP 800-171 Rev. 2)

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.14 (Control and monitor the use of Voice over Internet Protocol (VoIP) technologies).” (NIST SP 800-171 Rev. 2)

What the operator must do:
You need documented, repeatable controls that (a) restrict VoIP technologies to approved, managed implementations and (b) generate monitoring output you review and can produce as assessment evidence. Your assessor will look for both control design and proof of operation, aligned to CMMC’s Level 2 assessment expectations under the CMMC Program. (32 CFR Part 170) (DoD CMMC Program Guidance)

Plain-English interpretation

VoIP can carry sensitive discussions, voicemails, call recordings, and metadata. This practice expects you to:

• Control: decide which VoIP services, apps, devices, and features are allowed; block or disable the rest; and secure configurations.
• Monitor: collect logs/records that show how VoIP is being used and review them often enough to detect misuse and configuration drift.

“Control and monitor” is not satisfied by a policy alone. You need enforcement (network/identity/config) and monitoring evidence (logs + reviews + follow-up).

Who it applies to

Entities: Organizations pursuing CMMC Level 2 that process, store, or transmit CUI, including defense contractors and other federal contractors handling CUI. (32 CFR Part 170) (DoD CMMC Program Guidance)

Operational context (where this practice shows up):

• Cloud PBX / UCaaS (hosted VoIP)
• On-prem IP PBX
• Softphones on laptops and mobile devices
• Desk phones, conference room phones, call center stacks
• Voicemail-to-email, call recording, transcription, SMS/MMS in “unified communications”
• SIP trunks, session border controllers (SBC), and carrier interconnects
• Admin portals managed by IT or a third party provider

If any of these touch users or systems in your CUI environment, they are in scope for this control’s intent and should be included in your VoIP control and monitoring story.

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

1) Define your VoIP control scope and CUI rules of the road

1. State whether VoIP is allowed for CUI discussions and under what conditions (approved service only, no recording, no voicemail transcription, etc.).
2. Tie VoIP to boundary decisions: is VoIP inside the CUI enclave, outside it, or segmented with controlled gateways? Document the decision and the rationale.

Deliverable: a VoIP standard that clearly says what is permitted and what is prohibited, mapped to 3.13.14. (NIST SP 800-171 Rev. 2)

2) Build a complete VoIP inventory (the foundation assessors ask for)

Create and maintain an inventory that includes:

• VoIP platforms (UCaaS/PBX), tenant IDs, regions
• User accounts and admin roles
• Endpoints: desk phones, conference devices, softphones
• SIP trunks/SBCs, call routing, external numbers/DIDs
• Integrations: CRM, help desk, email (voicemail-to-email), recording storage, transcription
• Third parties operating any portion (managed service provider, carrier, UCaaS provider)

Practical tip: treat VoIP like any other critical service. Put it in your system inventory and your third-party inventory.

3) Restrict VoIP to approved services and block shadow VoIP

Implement at least one enforcement path (most teams use more than one):

• Network egress controls: restrict SIP/RTP and known VoIP service endpoints where feasible; require VoIP traffic to traverse approved paths (for example, through SBCs).
• Endpoint controls: block installation/use of unapproved softphone apps on managed endpoints; restrict mobile use via MDM app allowlists where applicable.
• Identity controls: enforce SSO/MFA for VoIP admin consoles and user portals; eliminate shared admin accounts; implement role-based access.

Assessment angle: you are demonstrating “control,” not just “guidance.”

4) Harden VoIP configurations (reduce data leakage paths)

Create a configuration baseline for your VoIP environment and apply it consistently:

• Disable or tightly control call recording, storage location, retention, access, and export.
• Control voicemail-to-email and transcription (both can place content into other systems).
• Restrict external call forwarding, simultaneous ring, and number porting workflows.
• Lock down admin role assignments and require strong authentication for privileged actions.
• Review encryption/security settings available in your VoIP stack and document what you enforce.

You do not need perfection; you need a clear baseline, applied settings, and evidence of ongoing management aligned to the practice language. (NIST SP 800-171 Rev. 2)

5) Turn on logging that supports monitoring and investigations

Enable and retain logs that show:

• Authentication events (especially admin logins, MFA events)
• Admin actions (policy changes, routing changes, role assignments)
• User provisioning changes (adds/removes, number assignment)
• Call detail records (CDRs) as appropriate for monitoring, with careful handling if they include sensitive metadata
• Recording enablement/disablement events and access to recordings (if recordings are allowed)

If your VoIP provider offers an audit log feed, export it to your central logging/SIEM or a controlled log repository.

6) Establish monitoring rules and a review workflow

Define what you look for and what you do when you see it:

• New admin creation or privilege escalation
• Call recording enabled unexpectedly
• Unusual forwarding rules (forward to external numbers)
• Logins from unexpected geographies or impossible travel patterns
• Unapproved endpoints registering to the system
• Sudden configuration changes to trunks/routing/SBC policies

Operationalize with tickets: each review produces “no findings” or documented follow-up.

7) Make it assessable: map, test, and capture recurring evidence

Assessors want to see that the control runs without heroics. Build a recurring evidence package:

• A control narrative mapped to 3.13.14
• Screenshots/exports of key configuration settings
• Samples of logs and review records
• Exceptions with approvals and compensating controls
• Proof that changes are managed (change tickets, approvals)

This aligns with the practical expectation to map the practice to documented control operation and recurring evidence capture. (DoD CMMC Program Guidance)

Required evidence and artifacts to retain

Use this as an evidence checklist you can hand to IT:

Evidence item	What it proves	Example artifacts
VoIP inventory	You know what exists and who owns it	CMDB entries, asset list, UCaaS tenant summary, SIP trunk list
VoIP policy/standard	You defined allowed/prohibited VoIP and features	“Approved VoIP Technologies Standard,” user guidance
Configuration baseline	You control VoIP settings	Admin portal screenshots, exported configs, SBC policy exports
Access control evidence	Only authorized users/admins access VoIP	RBAC matrix, MFA/SSO config screenshots, admin list with approvals
Monitoring/logging setup	You can monitor and investigate	Audit log settings, SIEM ingestion proof, sample CDR/audit logs
Review records	Monitoring is performed	Review checklist, dated tickets, alerts with triage notes
Change management	Configuration is controlled	Change requests for routing/recording/admin role changes
Third-party documentation	Provider responsibilities are known	Contract/SOW excerpts, shared responsibility notes

Common exam/audit questions and hangups

• “Show me all VoIP technologies in scope.” If you miss softphones or conference room devices, you will scramble.
• “How do you prevent unapproved VoIP apps?” A policy alone is weak; show endpoint or network enforcement.
• “Who can enable call recording and where does it store data?” Expect deep questioning if recordings/transcriptions exist.
• “What logs do you collect and who reviews them?” Have a named role, a checklist, and recent review artifacts.
• “How do you handle VoIP operated by a third party?” You still need control evidence: configuration, access, monitoring, and contract responsibilities. (DoD CMMC Program Guidance)

Frequent implementation mistakes (and how to avoid them)

1. Treating VoIP as “out of band.” Fix: include VoIP in the system boundary discussion and inventories.
2. Ignoring UCaaS feature sprawl (recording, transcription, SMS). Fix: baseline features explicitly; disable what you do not need.
3. No admin audit trail. Fix: enable provider audit logs and export them to your log repository.
4. No evidence of monitoring. Fix: create a lightweight recurring review ticket with attached log samples and documented outcomes.
5. Over-scoping without enforcement. Fix: if you allow VoIP for CUI discussions, ensure the specific approved path is controlled and monitored; otherwise prohibit it and enforce the prohibition.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so treat the driver as assessment failure and contractual risk under the CMMC Program rather than a published penalty example. (32 CFR Part 170) (DoD CMMC Program Guidance)

Operational risk is still real: VoIP environments commonly include external routing, mobile endpoints, and third-party-managed admin planes. Weak controls can create an unmonitored channel for sensitive discussions, recordings, or voicemails to leave your managed environment.

Practical 30/60/90-day execution plan

Use a phased plan to reach “assessable” quickly without inventing schedule guarantees.

First 30 days (Immediate stabilization)

• Assign ownership: IT Telecom/UC + Security + Compliance.
• Inventory all VoIP technologies, endpoints, and third parties.
• Decide and document: allowed VoIP services; whether CUI discussions are permitted; which features are disabled.
• Enable/confirm MFA/SSO for VoIP admin and user portals; remove shared admin accounts.
• Turn on audit logging in the VoIP platform and confirm you can export logs.

By 60 days (Control enforcement + monitoring live)

• Implement endpoint/network restrictions for unapproved softphones and risky VoIP traffic where feasible.
• Publish a configuration baseline (recording, transcription, forwarding, voicemail handling, admin roles).
• Integrate VoIP audit logs into centralized logging or a controlled repository.
• Stand up a monitoring checklist and start producing review tickets with outcomes and follow-ups.

By 90 days (Assessment-ready evidence pack)

• Run an internal mini-assessment for 3.13.14: test that blocked apps are blocked, privileged actions are logged, and alerts/reviews trigger tickets.
• Compile an evidence binder: policy, inventory, baseline, logs, review artifacts, and change records.
• Document exceptions (if any) with approvals and compensating controls.

Where Daydream fits: many teams fail this practice because evidence is scattered across UCaaS portals, IT tickets, and SIEM screenshots. Daydream can act as the system of record for mapping 3.13.14 to your control narrative and recurring evidence capture, so your assessor sees a clean thread from requirement to operation. (DoD CMMC Program Guidance)

Frequently Asked Questions

Does 3.13.14 mean we must ban VoIP?

No. It requires you to control and monitor VoIP use. If you allow it, you must enforce approved services and produce monitoring evidence. (NIST SP 800-171 Rev. 2)

Are Microsoft Teams, Zoom Phone, or other UCaaS tools considered VoIP under this practice?

If the technology provides voice calling over IP or unified communications that includes VoIP calling features, treat it as in scope for your VoIP control and monitoring approach. Your inventory and baseline should explicitly list the approved platforms.

What if our VoIP system is fully managed by a third party provider?

You still need to show control and monitoring outcomes: who has admin access, what configurations are enforced, what logs exist, and how reviews occur. Contracts help, but assessors still expect you to demonstrate operational oversight. (DoD CMMC Program Guidance)

Do we need to record calls or store call content to comply?

No. Compliance is about controlling and monitoring VoIP use, not recording content. If you do enable recording or transcription, treat it as sensitive data handling with strict access control, retention, and audit logs.

What evidence is usually hardest to produce during an assessment?

Teams often struggle with (1) a complete VoIP inventory, and (2) dated monitoring reviews with documented follow-up. Create a recurring review ticket pattern and attach log samples each time.

How do we handle softphones on employee mobile devices?

Decide whether mobile softphones are allowed in your CUI context. If allowed, enforce MDM controls, require strong authentication, and ensure logging and review cover those accounts and endpoints.