What SC.L2-3.13.14 requires for VoIP in a CMMC assessment
If phones, softphones or video conferencing run over IP and any of those calls carry CUI, SC.L2-3.13.14 applies to your system. The requirement has two parts that an assessor tests separately: controlling the use of Voice over Internet Protocol technologies and monitoring their use. Your organization must define which VoIP technologies are authorized, who may use them and for what, and then show that it watches for unauthorized or insecure use. Under 32 CFR 170.24 the requirement is worth 1 point, so it is a small share of the score, but a missing or unevidenced objective still leaves the requirement unmet and the assessor will test it.
The CMMC Assessment Guide Level 2 names two concerns that drive the requirement: *eavesdropping*, where someone intercepts voice conversations on the network, and *caller ID spoofing*, where an attacker presents a false identity to deceive staff. The same guide notes that a solution that encrypts VoIP traffic helps protect voice data, so encryption of the signaling and media paths is the first technical step to document. Confirm with your VoIP provider or platform vendor exactly which protocols and media encryption options the deployed system supports, and record the settings that are actually in force rather than the defaults in the product brochure.
The hard part is usually inventory and records, not the phones themselves. Common gaps include VoIP endpoints nobody registered, personal softphone apps installed on laptops that touch CUI, and video conferencing tools adopted by individual teams. Call detail records and registration logs are often kept by a hosted provider and never reviewed by your team. Start by building a list of every authorized and discovered VoIP endpoint, write a usage policy that names approved applications, and confirm that your logs (including boundary or intrusion detection records where they cover SIP or RTP traffic) are retained and reviewed. Your assessor will look for procedures and monitoring records that show the control operates, so draft those before the assessment.
Which VoIP systems and teams are in scope for SC.L2-3.13.14
Scope for SC.L2-3.13.14 starts with one question: does a voice system touch systems that store, process or transmit CUI? The cards below cover the voice channels most often in play, the boundary decision that has to be written down, and the current status of Phase II and Phase I obligations.
On-premises IP phone systems
Call managers, IP phones, voicemail servers and their administrative consoles are the classic VoIP assets. Confirm whether the call manager sits inside the assessment boundary, whether it shares a network segment with CUI systems, and who administers it. Administrative access to the phone platform is a separate control set, so record which accounts can change routing, recording and user settings.
Softphones on laptops and mobiles
Softphone clients on company laptops and phones often run on the same devices that open CUI files. Check whether these clients are installed on endpoints in scope, whether they are managed through your device controls, and whether personal devices can join calls that discuss CUI. Each device type creates a different monitoring and usage policy question.
SIP trunks from carriers
A SIP trunk carries voice traffic from your network to a carrier, so the traffic leaves your boundary even when the phones do not. Document the trunk endpoints, the signaling and media paths, and whether the carrier's service is treated as an external system. Ask the carrier how it protects call signaling and media, because eavesdropping and caller ID spoofing risks sit partly outside your environment.
Video and collaboration tools that carry voice
Meeting platforms, team chat clients and conferencing bridges carry voice as well as video and file sharing. Decide whether a meeting used for CUI discussions is in scope when the tool is hosted by a third party. Note the collaborative device control requirement, SC.L2-3.13.12, alongside this one, because microphones and cameras on these tools overlap with both requirements.
Third-party hosted VoIP services
A cloud-hosted phone service or contact center run by a provider is still part of the voice path your organization relies on. Review the provider's contract and security documentation, identify which of its controls you inherit, and confirm how the provider reports monitoring of unauthorized use. Record the decision in your system security plan so an assessor can trace the reasoning.
Documented boundary decisions and current status
Voice systems that never touch CUI systems may fall outside the assessment boundary, but that exclusion must be justified and written down with the network diagram and data flows. Phase II certification has been suspended by the Department of War, while Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Confirm the scope against current DoW CIO guidance before you finalize your boundary.
How an assessor tests VoIP control and monitoring
This table compares the two NIST SP 800-171A assessment objectives behind SC.L2-3.13.14, showing how an assessor tests each one, what evidence is requested and where organizations usually fall short. Read each row as one objective that must be satisfied, because a requirement is MET only when every applicable objective is met with evidence in final form, not drafts.
| Assessment objective | Test approach and evidence requested | Common findings |
|---|---|---|
| Controlling the use of VoIP technologies | Examine VoIP procedures, usage restrictions and implementation guidance. Interview administrators on who may deploy and use VoIP and how exceptions are approved. Test the mechanisms that restrict VoIP to authorized platforms, such as network rules or endpoint configuration, and request authorization records. | No written VoIP usage policy, or a policy that is not implemented in the network or on endpoints. Authorization records missing for approved softphones and hosted voice services. |
| Monitoring the use of VoIP technologies | Examine audit records and system monitoring records for VoIP traffic and call activity. Interview staff on how alerts are reviewed and who acts on them. Test that monitoring covers the VoIP paths in scope, including signaling and media where the design allows. | Call or VoIP logs collected but never reviewed. Monitoring covers the PBX but not remote or cloud-hosted softphones. No evidence that suspicious use, such as eavesdropping or caller ID spoofing indicators, is investigated. |
| Evidence of final-form procedures | Assessors expect approved, dated and version-controlled procedures, plus records showing they were followed during the assessment period. Drafts, unsigned guidance and undated notes generally do not satisfy an objective. | Policy exists only as a draft or wiki page with no owner. Records show the procedure was written after the assessment began. |
| Unmanaged softphones and endpoints | Interview administrators and review the device or application inventory for softphone clients installed on user devices. Test whether unapproved VoIP applications can be installed or used on systems that process CUI. | Personal or unapproved softphone apps used for business calls. No inventory of VoIP clients, so monitoring cannot cover them. |
How to implement VoIP control and monitoring step by step
This sequence moves from knowing which voice systems exist to proving they are used only as authorized and watched for misuse. Each step ends with a record an assessor can read, so the organization can show the requirement is met in practice, not just in policy.
Inventory every VoIP endpoint, service and trunk
Name the owner of the inventory, typically IT operations with input from the telecom or unified communications administrator. List every IP phone, softphone, soft client on laptops and mobile devices, VoIP gateway, session border controller, hosted or cloud calling service, SIP trunk and conferencing bridge that touches systems handling CUI. Record the platform, location, network path and the people or groups who use each one. Done means the list reconciles with what the network team sees on the wire, and any unknown voice device has been traced or removed. Ask your provider and platform vendors to confirm every component they operate so nothing is missed.
Define authorized VoIP technologies and usage restrictions
Write a VoIP usage policy that names the approved clients, protocols, providers and devices, and states what is prohibited, such as consumer messaging apps with voice features, unsanctioned softphones or calls placed over public VoIP services from work devices. Assign approval authority and a process for adding new technologies. Link each restriction to the inventory from the previous step. The output is a signed, versioned policy and an approved-technology list. Assessors look for procedures and usage restrictions that match what the system actually permits, so confirm that users and administrators received the policy and that the list is kept current.
Encrypt the voice path and confirm configuration
Configure the voice path so signaling and media are encrypted wherever the platform supports it, using the platform's secure signaling and secure media options and cryptography validated under FIPS requirements where the system protects CUI. Disable unencrypted fallback where the product allows it. Verify this with a configuration export or packet capture from a test call, showing that traffic is not sent in cleartext. The guidance for this requirement names eavesdropping and caller ID spoofing as core concerns, and encryption addresses the first. Ask the vendor to confirm which protocols and cipher options their product supports and which are only available on certain editions.
Separate voice systems from CUI processing
Place VoIP servers, gateways and endpoints that carry CUI-related calls on network segments that are controlled by the boundary rules already in place, so voice traffic cannot reach CUI systems except through defined paths. Restrict signaling and media ports to approved peers and deny other sources by default. Document the segmentation in the system security plan and capture the firewall or switch rules as evidence. The output is a network diagram showing voice segments, the rule set, and a test showing that unauthorized hosts cannot reach the voice control plane.
Enable monitoring of call and signaling records
Turn on call detail records, registration and authentication events, and signaling logs on each voice platform, and confirm the timestamps are synchronized with the rest of the environment. Forward these records to the central audit store used for other CUI systems, and confirm that administrators cannot silently disable logging. Test by placing a sample call and confirming the record appears in the store with the expected fields. Where intrusion detection covers the voice segment, direct alerts and logs to the same store. Open-source tools such as Suricata can produce structured EVE JSON records of protocol transactions and alerts, which can be sent to log management tools, but confirm that the protocol parsers and rules cover the specific VoIP protocols your environment uses.
Set alerting for unauthorized or insecure use
Define alert conditions that reflect the policy from step two. Examples include calls or registrations from unknown devices, use of unapproved clients, unencrypted signaling or media, repeated failed registrations, and calls to or from unapproved external providers. Route alerts to a named responder and document the expected response. Test each alert with a controlled event and keep the test record. Alerts should be tied to the incident response process so that a suspected eavesdropping or caller ID spoofing event is handled like any other security event.
Review logs and rules on a set cadence
Assign a reviewer, who should be independent of the voice administrator where practical, to review VoIP records, alerts and the approved-technology list on a schedule the organization defines in its policy. Record each review with the date, scope, findings and any follow-up tickets. Update the inventory, policy and rules when the review finds drift, such as new devices or changed providers. The completed review log is the evidence that monitoring is performed, not just configured. Confirm with your assessor what review frequency and format they expect for your environment before you finalize the procedure.
Assemble the evidence package for assessment
Collect the artifacts from each step into one folder mapped to the two assessment objectives for the requirement: controlling the use of VoIP technologies and monitoring their use. Include the final signed policy, the inventory, configuration exports, segmentation diagrams, sample audit records, alert tests and review logs. Make sure every document is in final form and dated, because drafts do not count toward a MET result. Ask your assessor, or the independent certification body if you are preparing for one, to confirm which artifacts they will request and how they want them organized.
Evidence that passes for VoIP usage control and monitoring
SC.L2-3.13.14 is assessed by checking that the organization controls how VoIP is used and monitors that use. The artifacts below connect policy, configuration, monitoring and follow-through, and an assessor will expect each one to agree with the others. Every item must be final and current on the day of the assessment, not a draft.
VoIP usage policy and approved list
This is the written rule set that defines which VoIP products, clients and providers may carry CUI-related calls, who may use them, and what is prohibited, such as personal softphone apps on managed devices. Assessors look for an approved technology list that matches what is actually deployed. Review it at least when a new VoIP platform or provider is added, and confirm the owner, approval date and version are recorded. Confirm with your assessor which format of usage restriction they accept.
System security plan VoIP entries
The system security plan should describe where VoIP sits in the system boundary, which components carry voice traffic, and how usage is controlled and monitored. Assessors compare these entries against the network diagram and the actual deployment. Keep the plan updated after any change to voice infrastructure, and make sure the plan states who is responsible for each monitoring activity.
VoIP inventory
An inventory lists every IP phone, softphone, gateway, session border controller, call manager and hosted VoIP service that touches the environment, with owner, location and network segment. Without it, unauthorized or forgotten devices are hard to find, and monitoring has no defined scope. Reconcile the inventory against network discovery results regularly, and record each removal so retired endpoints do not remain on the list.
Configuration exports for encryption and access
Exported settings from call managers, gateways and softphone policies show whether signaling and media are encrypted, which accounts can place or administer calls, and whether external dialing or remote registration is restricted. Assessors use these exports to test whether the controls described in policy are actually configured. Export them after every change window, store them under change control, and note the date and the person who ran each export.
Monitoring and audit records for VoIP sessions
Call detail records, registration logs, failed authentication events, and alerts for unusual call patterns or unexpected external connections show whether use is monitored. Where an intrusion detection sensor watches voice traffic, its EVE JSON alerts can serve as supporting evidence for detecting unauthorized or insecure use. Confirm log retention matches your audit policy and that the logs are time-stamped and protected from alteration.
Review records and training acknowledgments
Review records show that monitoring findings, such as toll fraud attempts, unapproved softphones or suspected caller ID spoofing reports, were triaged, assigned, and closed or tracked to completion. Training and acknowledgment records show that users and administrators received the VoIP usage rules and signed or accepted them. Keep dated sign-offs for each review, and check that every new hire and every changed role has a current acknowledgment on file.
What SC.L2-3.13.14 costs in money and effort
This table compares the cost components of meeting SC.L2-3.13.14 for VoIP, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written scope and to ask potential providers where their quote will land. The main takeaway is that this requirement is worth 1 point, but the labor for inventory, configuration and log review is real and should be quoted from a written scope rather than estimated from the point value.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| VoIP inventory and policy writing | One-time, staff time | Number of voice platforms, softphones, SIP trunks and conferencing tools in use, plus how many approvers the usage policy needs | Start from an existing telecom or collaboration inventory and reuse the organization's acceptable use policy structure |
| Configuration of encryption and access restrictions | One-time, engineering time | Whether the VoIP platform supports encrypted signaling and media, and how many endpoints and gateways must be reconfigured | Confirm platform capabilities with the vendor before scoping, and sequence changes in a maintenance window |
| Monitoring and log routing | One-time setup, then recurring storage and review | Volume of call detail records and security events, the logging destination, and retention periods set by the organization | Forward only the VoIP events the assessor will sample, and agree retention in the policy before building pipelines |
| Tooling or licenses | Recurring if commercial, one-time if open source | Commercial VoIP or session border controller licenses, and any paid support contracts for monitoring products | Open-source options remove license spend, but integration, testing and patching still require skilled labor |
| Evidence upkeep | Recurring | Frequency of usage reviews, change records for VoIP configuration, and periodic log reviews kept in final form | Schedule reviews into existing change and access review cycles and keep templates versioned |
| External review or testing | Optional, scoped in writing | Whether an outside party tests for eavesdropping or caller ID spoofing exposure, and the depth of that test | Limit scope to the VoIP systems that carry CUI and request a written statement of work before work starts |
| Auditor sampling | Set by the assessor | The assessor's sampling approach, the number of VoIP-related artifacts requested, and how many systems are in the assessment boundary | Keep a single current VoIP evidence folder so artifacts can be produced quickly; confirm sampling expectations with the assessor in advance |
Open-source tools that support VoIP monitoring evidence
The tools below watch network traffic and write records that an assessor can sample. They produce evidence for the monitoring objective of SC.L2-3.13.14, but they do not decide which VoIP technologies are allowed or who may use them. The policy, approved technology list and review process belong to the organization and must be documented and run as written.
OPNsense intrusion detection
OPNsense (BSD-2-Clause) includes a built-in intrusion detection and prevention system that runs Suricata. You can enable rulesets such as Emerging Threats and Abuse.ch, alert on or block matching traffic, and send alerts to syslog in EVE JSON format. Confirm the license terms of OPNsense and each ruleset before you rely on them in a contract. Check that the VoIP signaling and media paths cross the sensor, because traffic that never reaches the firewall produces no records. Confirm your SIP and RTP traffic is visible to the sensor.
Suricata EVE JSON records
Suricata (GPL-2.0-only) writes EVE output as JSON records for rule alerts, flows and protocol transactions such as TLS and DNS. Those records can be split into separate files so a log management tool can index VoIP-related alerts apart from other traffic. The GPL-2.0-only license has obligations if you modify and distribute the software, so have counsel review how your deployment is packaged. Confirm which protocol transactions your rules and VoIP platform actually generate, since some signaling may only appear as flow data.
Alert review and retention
Sensor output is only evidence if someone reviews it and keeps it. Document who reviews VoIP alerts, how often, and what triggers escalation, such as calls from unapproved endpoints, repeated registration failures or traffic to unexpected destinations. Keep the review records with the sensor logs so an assessor can trace an alert to a decision. Confirm your retention period with the system security plan and the audit requirements that apply to the same logs.
Web management interface protection
If a VoIP platform exposes a web-based administration or self-service portal, that interface is a web application and can be attacked like one. Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx. It addresses injection and cross-site scripting attacks against that portal, not VoIP call traffic itself. Include it only if the portal is reachable from outside your boundary, and confirm which proxy your platform uses before choosing an integration.
Who does what for SC.L2-3.13.14: your team, a partner and the assessor
Your organization owns SC.L2-3.13.14 in full. The requirement asks you to control and monitor the use of VoIP technologies, so the decisions about which voice services are permitted, who may use them and what counts as unauthorized use belong to you. Those decisions must be written down, approved by people accountable for the system, and applied to the systems that actually carry voice traffic in your environment.
- Usage policy: Write and approve the VoIP usage restrictions and implementation guidance, including approved softphones, endpoints and providers.
- VoIP inventory: Maintain a current list of every VoIP service, softphone, gateway and hosted voice account that touches the system boundary, including shadow services people install on their own devices.
- Authorization decisions: Record who approved each service, under what conditions, and when that approval is reviewed.
- Monitoring review: Someone on your staff reads the monitoring output on a set cadence, investigates anomalies such as unusual call patterns or unexpected registrations, and documents the outcome.
- Remediation: Block or remove unauthorized voice services and track any gaps in a plan of action.
Before an assessment, confirm that each of these records is in final form, dated and signed, because drafts do not satisfy the objectives.
An implementation partner such as DeployOpen can help you build the technical side of the requirement. The partner prepares systems and evidence inside your infrastructure. It does not decide whether your controls meet the requirement, and it does not issue findings, reports or certifications. The organization remains accountable for its controls and for every affirmation it makes.
- Monitoring stack: Configure the boundary and logging components that observe VoIP-related traffic, for example an intrusion detection system with rules for voice protocols, and route alerts to your log management tools.
- Boundary and logging configuration: Set up the parts of the boundary that enforce your approved VoIP usage, and document the configuration as it is deployed.
- Evidence assembly: Collect configuration exports, alert records, log samples and review tickets into an organized evidence set that maps to the assessment objectives.
- Gap analysis: Identify where the inventory, logs or procedures fall short and report those gaps to your team for decision.
- Scope of the engagement: Agree the deliverables in writing before work begins, so responsibilities for policy, operation and evidence are clear.
Ask any partner to show you which artifacts it will produce and which ones your own staff must own and sign.
The assessor tests whether the requirement is met and decides the result. For Level 2 certification, that is a C3PAO authorized or accredited by The Cyber AB. For Phase I, the self-assessment process applies, in which your organization performs the assessment itself and records its results. Whatever the path, the assessor works against the assessment objectives in NIST SP 800-171A, and a requirement is MET only when every applicable objective is satisfied with evidence in final form.
- Objective testing: The assessor examines the VoIP procedures and usage restrictions, then interviews staff and tests whether controls operate as described.
- Independence: A partner that helped build the monitoring stack cannot also serve as the certification assessor for the same environment.
- Sampling and observation: The assessor may select records, check monitoring output and verify that reviews happened on schedule.
- Findings and status: Only the assessor records findings and the outcome for the requirement, and the result feeds into your overall score and status.
- Your affirmations: Your senior official remains responsible for the accuracy of the posted status and annual affirmations, regardless of who helped prepare the evidence.
Before engaging anyone, confirm the assessor's authorization status and the assessment path that applies to your contract.
Where organizations fall short on VoIP controls and how to close each gap
Most VoIP shortfalls under SC.L2-3.13.14 are not technical failures. They are missing decisions, uninventoried systems and records that exist but cannot be shown to an assessor. Each card below pairs a common gap with the fix and the evidence that closes it.
No written VoIP policy or approved list
Assessors look first for the usage restrictions and implementation guidance that define which VoIP technologies may carry business voice and who may authorize them. Without a written policy and an approved list of platforms, softphones and SIP trunks, the organization cannot show it controls VoIP use at all. Write the policy, name an owner, list approved products with their versions, and record who signed off. Confirm the approval process covers new platforms before they reach users.
Unmanaged softphones on personal devices
Staff who place calls from personal phones or laptops using consumer VoIP apps bypass every boundary and logging control the organization has built. The fix is a device rule that states which endpoints may run approved softphone clients, enforced through mobile device management or a configuration baseline. Keep an inventory of endpoints with approved clients and check it against directory records during each review cycle.
VoIP traffic not encrypted or inventoried
The CMMC Assessment Guide names eavesdropping and caller ID spoofing as VoIP concerns, and says encrypting VoIP traffic helps protect voice data. Many organizations cannot say which calls cross the boundary unencrypted because they never listed their SIP trunks, call managers or media paths. Build an inventory of every VoIP component and its transport settings, then confirm encryption for signaling and media on each one. Keep the configuration exports as evidence.
Monitoring enabled but records never reviewed
A gateway that logs call setup and flags anomalies only satisfies the monitoring objective if someone reviews the output on a defined schedule and acts on what they find. Intrusion detection rules such as those in OPNsense with Suricata can alert on unusual VoIP protocol activity, and EVE JSON output can feed a log tool. Assign a reviewer, set a review cadence, and keep dated review records with the findings and follow-up tickets.
Evidence written as drafts
A requirement is met only when every applicable assessment objective is satisfied with evidence in final form, not drafts. A VoIP policy stuck in revision, or a monitoring procedure never approved, will fail even when the practice is working. Put each document under version control, record the approver and effective date, and retire superseded copies. Before an assessment, confirm that each artifact the assessor will request has a final version and a date that matches the system as it runs today.
Questions about cost, effort and doing SC.L2-3.13.14 in-house
How much effort does SC.L2-3.13.14 take compared with other SC requirements?
It is one of the lighter system and communications protection requirements in effort, because it is worth 1 point and asks for two things: control over VoIP use and monitoring of that use. Most of the work is documentation and inventory, not engineering. Requirements such as SC.L2-3.13.1 boundary protection or SC.L2-3.13.11 CUI encryption usually take more time because they involve firewall rule sets, validated cryptography and architecture changes. The effort for 3.13.14 grows with the number of VoIP systems you run, how many people can use them, and whether voice traffic crosses networks that also carry CUI. A small, well-documented VoIP estate is a short task. A distributed one with several providers takes longer.
Can a small team handle SC.L2-3.13.14 without outside help?
Often yes, if the team has someone who knows the phone system and someone who can write policy. The requirement needs a VoIP usage policy, an approved list of technologies, and records showing that use is monitored for unauthorized or insecure activity. A small team can write the policy, tie it to existing firewall or logging tools, and collect records. Outside help is most useful when the phone system is hosted by a third party, when no one on staff understands call traffic well enough to judge what counts as unusual, or when assessors have already rejected earlier evidence. Whatever you choose, the organization owns the control and the assessor, not the consultant, decides whether the evidence meets the objectives in NIST SP 800-171A.
What does the work need from our organization?
Three inputs matter most. First, access to an inventory of every VoIP platform, softphone, session border controller and hosted provider that carries business calls. Second, a named decision maker who can approve the usage policy and the list of allowed technologies. Third, platform administrator time to pull call detail records, configuration exports and monitoring output. Expect the administrators to spend time on evidence collection, not only on configuration. If your monitoring output lives in a managed hosted service, confirm early what logs you can export and in what format, because that determines how much of the monitoring objective you can show directly.
Can SC.L2-3.13.14 go on a POA&M if we are not ready?
Possibly, but confirm the current rules before relying on it. SC.L2-3.13.14 is a 1-point requirement that is not on the exclusion list in 32 CFR 170.21, so under the rule text it may be placed on a plan of action and milestones for Conditional Level 2 status when the score is at least 88 of 110, with closeout due within 180 days. The Department of War suspended CMMC Phase II on 13 July 2026 and began a review by a reform task force, so the timing and enforcement picture may have changed. Check the current eCFR text, the DoW CIO About CMMC page and your contracting officer before you plan around a POA&M.
What drives the cost of SC.L2-3.13.14 up or down?
The main drivers are the number of VoIP systems in scope, whether they are hosted or on premises, and how much monitoring data you already collect. Costs are one-time for policy writing, inventory, and initial configuration, and recurring for log review, access reviews and periodic evidence refreshes. A hosted provider that exports detailed records lowers the monitoring cost. A system with no logging needs new tooling, such as a boundary inspection or intrusion detection feed, which adds licensing and staff time. Whether the phones are encrypted in transit is part of the broader cryptography work under other SC requirements, so it can be scoped separately.
What should we ask a partner to include in a written scope?
Ask for a scope that names each VoIP system, provider and network segment in the assessment boundary, and lists the policy, procedure and monitoring deliverables. Request a clear split of responsibilities: what your team owns, what the partner prepares, and what an independent assessor will test. Ask how monitoring records will be collected, reviewed and retained, and which evidence will show the two assessment objectives are met. Confirm the timeline, the review points, and what happens if the current CMMC rules change. DeployOpen works from fixed, written scope, so a quote follows from that document rather than a standard price list.
How DeployOpen scopes and prepares SC.L2-3.13.14 evidence
DeployOpen works on SC.L2-3.13.14 by agreeing a written scope for the VoIP technologies in your environment, then preparing the usage policies, monitoring and evidence an assessor will examine. The organization keeps ownership of its controls, and only an independent assessor can judge whether the requirement is met.
How we scope
- Engagements are fixed-scope, with the VoIP systems, networks and boundaries in scope agreed in writing before work starts.
- We inventory which voice platforms, softphones and VoIP gateways carry or could carry CUI within the assessment boundary.
- The written scope states which systems are covered and which are excluded, so the evidence matches what an assessor will test.
How we build
- We help draft VoIP usage restrictions and authorization procedures that define approved technologies and who may configure them.
- We configure monitoring for VoIP traffic and related logs, and we review whether encryption of voice traffic is in place where it is used.
- We document how unauthorized or insecure VoIP use is detected, including eavesdropping and caller ID spoofing indicators, with alert routing defined.
How we hand over
- We deliver the written procedures, configuration records and monitoring evidence in final form, mapped to the two assessment objectives for 3.13.14.
- Handover includes a short walkthrough so your team can show how each objective is evidenced during an assessment.
- We confirm with you which items must be retained, who owns them and where they are stored, so that evidence stays current.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover periodic review of VoIP monitoring records and updates to usage policies as systems change.
- Before engaging, ask the independent assessor which evidence formats they accept and confirm them with us in the written scope.
