Ringer and Ringer Affiliate companies
1. Regulatory Intent and Construction
This DPA is intended to operationalize U.S. telecommunications privacy, data-security, breach, customer-authentication, anti-robocall, TCPA, E911, state privacy, and lawful-request obligations applicable to Carrier Data.
For this DPA, “IPES” means IP-enabled services, including interconnected VoIP and outbound-only VoIP services where applicable. The parties acknowledge that telecommunications carriers have a federal duty to protect proprietary information of customers, other carriers, equipment manufacturers, and resellers, and that CPNI may only be used, disclosed, or accessed as permitted by law, customer approval, or service necessity. 47 U.S.C. § 222 defines CPNI to include information relating to the quantity, technical configuration, type, destination, location, and amount of use of a telecommunications service, and billing information, excluding subscriber-list information. (Legal Information Institute)
The parties further acknowledge that FCC CPNI rules require approval tracking, personnel training, disciplinary processes, records of CPNI disclosures and marketing campaigns, supervisory review for outbound marketing, annual certification, authentication before CPNI disclosure, immediate account-change notices, and special CMRS/SIM-change safeguards where applicable. ([eCFR][2])
For SMS and SMPP services, the parties recognize that SMPP interfaces move short message data between ESMEs, routing entities, and message centers, and may include source and destination addressing, message content or payload, delivery receipts, message IDs, message state, billing identifiers, network-error codes, and related telemetry; this DPA treats those fields as Carrier Data and, where identifiable, as CPNI, personal information, or both.
2. Definitions
“Affiliate” means any entity controlling, controlled by, or under common control with a party.
“Applicable Law” means all federal, state, local, and sector-specific laws, rules, regulations, orders, consent decrees, regulator guidance, and lawful orders applicable to the processing of Carrier Data, including, as applicable: the Communications Act, FCC rules, CPNI rules, TCPA, TRACED Act obligations, CALEA, E911/NG911 rules, state privacy laws, state breach laws, GLBA Safeguards Rule, HIPAA where healthcare traffic is involved, COPPA where children’s data is involved, and applicable carrier messaging rules.
“Carrier Data” means all data processed by Processor on behalf of Carrier or Carrier’s customers, including CPNI, Customer Proprietary Information, Personal Data, SMS/MMS/RCS message data, SMPP PDUs and logs, SIP signaling data, call detail records, IPDRs, session metadata, account data, authentication data, consent data, numbering data, location data, E911 data, porting data, SIM/eSIM data, KYC/KYB data, fraud/risk scores, routing data, billing data, payment tokens, trouble-ticket data, lawful-request data, and security logs.
“CPNI” means customer proprietary network information as defined by 47 U.S.C. § 222 and 47 C.F.R. Part 64 Subpart U, including call/text/message records, technical configuration, type, destination, location, amount of use, service usage, and billing information associated with telecommunications services.
“Customer Proprietary Information” means CPNI plus personally identifiable information, account credentials, authentication artifacts, proprietary carrier-to-carrier information, reseller information, and other customer information protected by FCC rules, state law, or contract.
“Personal Data” means any information that identifies, relates to, describes, is reasonably capable of being associated with, or can reasonably be linked to an individual, household, device, subscriber, end user, business contact, or customer account.
“Processing” means any operation performed on Carrier Data, including collection, receipt, access, storage, use, disclosure, retrieval, consultation, transmission, routing, enrichment, scoring, aggregation, analysis, blocking, return, deletion, or destruction.
“Security Incident” means any actual or reasonably suspected unauthorized access, use, acquisition, disclosure, loss, alteration, destruction, compromise, exfiltration, or unavailability of Carrier Data, systems processing Carrier Data, or credentials used to access Carrier systems.
“Breach” means a Security Incident that triggers notification, investigation, reporting, or remediation obligations under Applicable Law or this DPA.
“Subprocessor” means any third party or Affiliate engaged by Processor to process Carrier Data.
3. Order of Precedence
If there is a conflict among the main services agreement, this DPA, a statement of work, an order form, an information-security exhibit, or a business associate agreement, the order of precedence is:
1. mandatory Applicable Law;
2. business associate agreement, if HIPAA applies;
3. this DPA;
4. security exhibit;
5. service-specific order or SOW;
6. main services agreement.
Nothing in this DPA limits obligations required by Applicable Law.
4. Roles of the Parties
Carrier is the controller/business for Carrier Data except where the parties expressly agree otherwise in an exhibit.
Processor is a processor/service provider/contractor with respect to Carrier Data and shall process Carrier Data only on Carrier’s documented instructions, including this DPA, the applicable order, Carrier’s written policies provided to Processor, lawful routing instructions, fraud-mitigation instructions, emergency-service instructions, and regulator or law-enforcement instructions approved by Carrier.
Processor shall immediately notify Carrier if Processor believes an instruction violates Applicable Law, unless prohibited by law.
Processor shall not determine the purposes or means of processing Carrier Data except as strictly necessary to provide the contracted services and comply with lawful obligations.
State privacy laws commonly require processor contracts to specify processing instructions, nature and purpose of processing, data types, processing duration, confidentiality, deletion/return, audit, and subcontractor obligations. Virginia’s Consumer Data Protection Act is one example of that structure, and California’s CCPA regulations require service-provider/contractor limits on retaining, using, disclosing, combining, or subcontracting personal information outside the permitted business purpose. (Virginia Law)
5. Permitted Processing
Processor may process Carrier Data only to:
a. provide voice, messaging, IP-enabled, numbering, emergency-service, routing, analytics, fraud-control, billing, support, hosting, monitoring, NOC, compliance, or other contracted services;
b. maintain network security, detect and prevent fraud, spam, illegal robocalls, illegal robotexts, spoofing, SIM-swap fraud, port-out fraud, account takeover, abuse, and service misuse;
c. comply with lawful process, CALEA obligations, traceback requests, emergency-service duties, regulator inquiries, and court orders, subject to Section 20;
d. create aggregated or de-identified data only as permitted by Section 17; and
e. perform internal service operations reasonably necessary to provide, secure, debug, monitor, improve, and support the contracted services, provided that Processor does not use identifiable Carrier Data for cross-customer advertising, unrelated product development, AI training, data brokerage, or profiling unless expressly authorized in writing by Carrier.
6. Prohibited Processing
Processor shall not:
a. sell, rent, lease, disclose, license, or otherwise monetize Carrier Data;
b. use Carrier Data for Processor’s own marketing, customer acquisition, advertising, retargeting, enrichment, data brokerage, or unrelated analytics;
c. combine Carrier Data with data from other customers, data brokers, public sources, advertising networks, or Processor’s own consumer relationships except as expressly permitted by Applicable Law and Carrier’s written instructions;
d. use Carrier Data to train, fine-tune, evaluate, or improve generative AI, LLMs, voice biometric models, fraud models, spam models, or analytics models unless expressly authorized in a signed AI/data-use exhibit;
e. access message content, call content, voicemail content, lawful-intercept content, or emergency-call content except as necessary to provide the service, troubleshoot a specific ticket, comply with lawful process, or protect the network;
f. disclose CPNI to affiliates, agents, or third parties for marketing unless Carrier has documented the legally required customer approval and instructed Processor to do so;
g. use local-service CPNI to identify or track customers calling competing providers; or
h. knowingly assist illegal calls, illegal texts, unlawful spoofing, phishing, smishing, spam, SIM-swap fraud, or traffic pumping.
FCC rules allow certain uses of CPNI without customer approval for service provision, certain related marketing, fraud/abuse prevention, and specified service categories, but otherwise require customer approval for individually identifiable CPNI use or disclosure. ([eCFR][4])
7. CPNI-Specific Obligations
Processor shall maintain controls that allow Carrier to clearly establish the approval status for any CPNI use or disclosure before such use or disclosure occurs.
Processor shall process CPNI only for the telecommunications service from which the CPNI is derived, services necessary to or used in providing that telecommunications service, billing and collection, fraud and abuse prevention, emergency services, lawful process, or other purposes expressly authorized by Carrier and Applicable Law.
Processor shall maintain records of all CPNI disclosures, third-party access, campaigns, use cases, and approval evidence for at least one year, or longer if required by Carrier’s retention schedule.
Processor shall train all personnel with access to CPNI on authorized and prohibited uses of CPNI and shall maintain a documented disciplinary process for unauthorized access, use, or disclosure.
Processor shall support Carrier’s annual CPNI certification process by providing, on request, evidence of operating procedures, complaints, disclosures, broker-related actions, third-party access, and remedial measures.
Processor shall not disclose call-detail information, text-detail information, location information, or account information through a support channel unless the requester has been authenticated under Carrier-approved procedures.
8. Customer Authentication, Account Changes, SIM/eSIM, and Porting
Processor shall use authentication methods approved by Carrier before disclosing CPNI or performing account changes, SIM changes, eSIM provisioning, port-out approvals, password resets, address changes, number assignments, number releases, call-forwarding changes, or routing changes.
Processor shall not authenticate using readily available biographical information, account information, recent payment information, call-detail information, or other weak knowledge-based methods unless Carrier confirms such method is legally permitted for the specific use case.
Processor shall immediately notify Carrier of account-change events requiring customer notice, including password creation or change, backup authentication change, online account change, address-of-record change, SIM/eSIM change, port-out request, port-out completion, or other high-risk account event.
For CMRS, wireless reseller, MVNO, or eSIM services, Processor shall maintain safeguards against SIM-swap and port-out fraud, including employee training, privileged-access restrictions, account-lock workflows, step-up authentication, and escalation paths for suspected victims.
FCC rules require reasonable measures to discover and protect against unauthorized access to CPNI, customer authentication before CPNI disclosure, account-change notices, and CMRS SIM-change authentication safeguards. ([eCFR][5])
9. TCPA, Consent, Messaging, and Marketing Controls
Where Processor supports outbound calls, SMS, MMS, RCS, ringless voicemail, fax, or campaign messaging, Processor shall:
a. process consent, opt-in, opt-out, revocation, DNC, quiet-hour, sender-ID, campaign-registration, and suppression data only on Carrier’s instructions;
b. maintain proof of consent, source, timestamp, language, phone number, seller, campaign, and revocation status where Carrier requires it;
c. support STOP, HELP, unsubscribe, DNC, and revocation workflows;
d. propagate opt-out and suppression events to downstream systems in near real time and no later than the time required by Carrier;
e. not initiate or enable telemarketing, advertisement, autodialed, prerecorded, artificial voice, or robotext traffic unless Carrier has instructed that required consent exists;
f. not alter message content, sender identity, originator, caller ID, or campaign attributes in a manner that causes noncompliance; and
g. retain consent and suppression logs for the longer of Carrier’s retention schedule or the applicable limitations period.
FCC TCPA rules restrict autodialed or artificial/prerecorded calls to wireless and other protected numbers without required consent, require prior express written consent for telemarketing or advertising calls using autodialer or artificial/prerecorded voice, treat certain SMS messages as “calls,” define prior express written consent, and require DNC procedures and honoring DNC requests. ([eCFR][6])
10. Robocall, Robotext, Spoofing, STIR/SHAKEN, Traceback, and Abuse
Processor shall maintain operational controls to help Carrier comply with robocall, robotext, spoofing, traceback, call/text blocking, and STIR/SHAKEN obligations, including:
a. KYB/KYC due diligence for customers, resellers, upstream providers, downstream providers, aggregators, and campaign originators;
b. screening against sanctions, law-enforcement, regulatory, traceback, high-risk campaign, high-risk reseller, and abuse lists;
c. procedures to identify, investigate, suspend, block, rate-limit, or terminate illegal or abusive voice and messaging traffic;
d. preservation and timely production of call path, SIP, trunk group, IP, OCN, CIC, carrier, campaign, sender, reseller, customer, and message/call metadata required to respond to traceback or regulator inquiries;
e. cooperation with Carrier to meet 24-hour traceback response commitments;
f. support for do-not-originate lists, reasonable analytics, erroneous blocking redress, and message-blocking points of contact where Processor provides blocking or analytics services; and
g. no modification, stripping, downgrading, or misrepresentation of STIR/SHAKEN identity headers, attestation, originating identity, or traceback-relevant metadata except as authorized by Carrier and Applicable Law.
FCC rules require robocall mitigation programs for voice, gateway, and intermediate providers, include commitments to respond to traceback requests within 24 hours, require reasonable steps to avoid illegal traffic, and require customer/upstream-provider due diligence. ([eCFR][7]) FCC rules also require voice service providers to fully respond to traceback requests within 24 hours, investigate suspected illegal traffic, block or cease accepting identified illegal traffic where required, and take effective measures to prevent new and renewing customers from using their networks to originate illegal calls. ([eCFR][6])
11. E911, NG911, Location, and Emergency Services Data
If Processor supports E911/NG911, interconnected VoIP, outbound-only VoIP, nomadic VoIP, MLTS, wireless location, ALI, LIS, PIDF-LO, routing, geolocation, or emergency-call handling, Processor shall:
a. process emergency-service data solely to provide, route, support, validate, test, troubleshoot, or comply with emergency-service obligations;
b. maintain accurate registered-location, dispatchable-location, ANI, pseudo-ANI, callback, ALI, LIS, routing, and PSAP delivery data as instructed by Carrier;
c. provide mechanisms for end users or Carrier to update Registered Location where Processor provides the relevant customer-facing or provisioning system;
d. maintain heightened access controls and audit logs for location and emergency-service records;
e. not use emergency-service location data for marketing, profiling, analytics, or monetization;
f. notify Carrier immediately of any emergency-routing outage, PSAP delivery issue, ALI/LIS failure, location-update failure, or data-quality issue that could affect 911 service; and
g. preserve records for emergency calls and routing events as required by Carrier.
FCC E911 rules for interconnected VoIP require E911 service, transmission of 911 calls, ANI and location information to the appropriate PSAP or authority, location requirements for fixed and non-fixed interconnected VoIP, Registered Location update mechanisms, and customer notices/acknowledgments regarding E911 limitations. ([eCFR][8])
12. Confidentiality and Personnel Controls
Processor shall ensure that all personnel with access to Carrier Data are bound by written confidentiality obligations no less protective than this DPA.
Processor shall limit access to Carrier Data to personnel with a legitimate need to know for the contracted services.
Processor shall maintain onboarding, background-screening where legally permitted and appropriate, role-based training, CPNI training, security training, acceptable-use policies, disciplinary procedures, and prompt access termination when personnel no longer require access.
Processor shall maintain separate support roles for privileged telecom functions, including lawful intercept, E911, SIM/eSIM, number porting, CPNI disclosure, fraud blocking, traceback, and customer account changes.
13. Minimum Security Program
Processor shall implement and maintain a written information-security program appropriate to the nature, scope, sensitivity, and volume of Carrier Data and the criticality of telecommunications services.
At a minimum, Processor shall maintain:
a. designated security leadership;
b. written risk assessments;
c. asset inventory and data-flow mapping;
d. least-privilege access controls;
e. MFA for administrative, remote, production, and Carrier Data access;
f. encryption in transit over external networks and at rest where feasible;
g. key management and secrets management;
h. secure SDLC and code review;
i. vulnerability management and patching;
j. logging, monitoring, and alerting;
k. endpoint and server hardening;
l. network segmentation;
m. backup, recovery, and business continuity;
n. incident response plan;
o. vendor risk management;
p. annual penetration testing or continuous testing appropriate to risk;
q. periodic vulnerability scanning;
r. secure disposal;
s. change management;
t. employee security awareness training;
u. data-loss prevention or equivalent controls for high-risk repositories;
v. production-access approval and session logging;
w. physical security for facilities; and
x. annual review of the security program.
If GLBA-regulated financial products, handset financing, installment billing, credit checks, collections, or customer financial information are in scope, Processor shall implement safeguards consistent with the FTC Safeguards Rule, which requires risk assessment, access controls, encryption or compensating controls, secure development, MFA, secure disposal, monitoring/logging, testing, training, service-provider oversight, incident response, and board/senior-officer reporting. ([eCFR][9])
14. Technical Security Requirements for Telecom Data
Processor shall maintain telecom-specific controls, including:
a. SIP trunk, SMPP bind, API, portal, and admin access controls by IP, certificate, key, credential, customer, system ID, account, and role;
b. rotation and revocation of SMPP passwords, API keys, SSH keys, SIP credentials, portal credentials, database credentials, and encryption keys;
c. per-customer logical separation for routing, rating, CDRs, SDRs, SMPP logs, message bodies, campaign data, and billing data;
d. controls to prevent unauthorized routing-table, rate-deck, LCR, SMS route, DNO, CNAM, E911, DID, SIM/eSIM, or number-porting changes;
e. integrity controls for CDR/SDR/IPDR generation, reconciliation, mediation, rating, invoicing, and dispute evidence;
f. detection of anomalous traffic, high-cost destination spikes, traffic pumping, CLI spoofing, sender-ID abuse, velocity spikes, brute force bind attempts, invalid bind attempts, and routing loops;
g. redaction or tokenization of message content, call recordings, OTPs, passwords, PINs, SSNs, payment data, and sensitive ticket attachments where feasible;
h. masking of CPNI and call detail in support tools by default;
i. emergency break-glass access with approval, logging, post-review, and expiration;
j. secure interconnection over TLS, VPN, private interconnect, IPsec, mTLS, or equivalent controls where supported;
k. segregation of lawful-intercept systems and records from ordinary support access; and
l. tamper-evident logs for regulated workflows.
15. Subprocessors
Processor shall not appoint a Subprocessor to process Carrier Data without Carrier’s prior written authorization, either specific or general.
Where general authorization is granted, Processor shall:
a. maintain a current Subprocessor list;
b. provide at least 30 days’ prior notice of new Subprocessors, unless emergency replacement is required for security or continuity;
c. allow Carrier to object on reasonable regulatory, security, sanctions, location, or confidentiality grounds;
d. impose written obligations on each Subprocessor no less protective than this DPA;
e. remain fully liable for Subprocessor acts and omissions; and
f. ensure Subprocessors do not process Carrier Data outside the authorized purposes.
Subprocessor contracts must include confidentiality, security, breach notice, deletion/return, audit/assessment, assistance, processing limits, and onward-subprocessor restrictions.
16. Cross-Border Processing and Data Localization
Processor shall not transfer, access, support, store, or process Carrier Data outside the United States unless authorized in writing by Carrier.
If approved, Processor shall identify the countries, data categories, purposes, support teams, subprocessors, and safeguards.
Processor shall not move E911, lawful-intercept, CALEA, customer-authentication, SIM/eSIM, porting, regulated CPNI, or government/customer-proprietary data outside the United States unless the applicable order expressly permits it.
Processor shall comply with sanctions, export-control, supply-chain, Team Telecom, FCC, law-enforcement, and national-security restrictions applicable to Carrier Data, network access, support access, or vendor ownership.
17. Aggregated, De-Identified, and Derived Data
Processor may create aggregated or de-identified data only if:
a. Carrier Data cannot reasonably be used to identify Carrier, Carrier’s customers, subscribers, end users, traffic partners, routes, rates, accounts, numbers, devices, locations, or network behavior;
b. Processor publicly or contractually commits not to re-identify the data;
c. Processor imposes equivalent commitments on recipients;
d. the data is not used to disadvantage Carrier or Carrier’s customers;
e. the data is not used for targeted advertising, lead generation, credit decisions, eligibility decisions, data brokerage, or law-enforcement sale; and
f. Carrier has not opted out of such use.
Derived risk scores, reputation scores, route-quality scores, fraud scores, spam scores, and blocking scores remain Carrier Data to the extent they are generated from identifiable Carrier Data or materially affect Carrier traffic.
18. Data Retention and Deletion
Processor shall retain Carrier Data only for the period specified in Annex A or Carrier’s written retention schedule.
Processor shall delete or return Carrier Data upon Carrier’s request, upon expiration of the retention period, or upon termination of the services, unless retention is required by Applicable Law, litigation hold, regulator order, lawful process, billing dispute, fraud investigation, tax obligation, or network-security necessity.
Processor shall maintain deletion logs and certify deletion on request.
Processor shall not retain message content, call content, OTPs, passwords, PINs, payment data, or identity documents longer than necessary for the specific purpose.
Processor shall periodically review retention settings to minimize unnecessary retention.
19. Security Incident and Breach Notification
Processor shall notify Carrier without undue delay and in no event later than 24 hours after becoming aware of a Security Incident involving Carrier Data or Carrier systems.
The notice shall include, to the extent known:
a. incident date and discovery date;
b. affected systems, accounts, APIs, SMPP binds, SIP trunks, databases, logs, queues, tickets, or subprocessors;
c. categories and approximate volume of affected Carrier Data;
d. affected customers, subscribers, phone numbers, accounts, campaigns, routes, or carriers;
e. whether CPNI, Customer Proprietary Information, location data, message content, call content, authentication data, government data, E911 data, payment data, or identity data is involved;
f. containment steps;
g. known or suspected cause;
h. whether credentials, keys, certificates, tokens, or encryption keys were accessed;
i. whether data was encrypted, redacted, tokenized, or otherwise protected;
j. remedial measures;
k. law-enforcement or regulator contact, if any; and
l. Processor’s incident commander and legal/security contacts.
Processor shall provide updates at least every 24 hours until containment, and thereafter as reasonably requested by Carrier.
Processor shall not notify regulators, customers, subscribers, the press, counterparties, traceback consortiums, or law enforcement about a Security Incident involving Carrier Data without Carrier’s prior written approval, unless Processor is legally required to do so. If Processor is legally required to notify, it shall provide Carrier prior notice unless prohibited by law.
Processor shall preserve forensic evidence, logs, images, tickets, access records, network captures, SIEM alerts, affected credentials, and relevant communications.
Current FCC CPNI breach rules require telecom carriers to notify USSS and FBI through a central reporting facility as soon as practicable and no later than seven business days after reasonable determination of a CPNI breach, and restrict customer/public notice until the law-enforcement notice process is completed. ([eCFR][10]) The FCC’s 2024 Data Breach Reporting Order adopted amendments that would expand covered data and require FCC/USSS/FBI notice within seven business days and customer notice without unreasonable delay, no later than 30 days, but the Federal Register states that the revised recordkeeping/reporting requirements require OMB approval and that unmodified rules continue until approval. This DPA’s 24-hour processor notice is designed to let Carrier comply with either current or amended FCC timelines. ([Federal Register][11])
20. Lawful Requests, CALEA, Subpoenas, and Regulator Inquiries
Processor shall promptly notify Carrier of any subpoena, warrant, court order, CALEA request, pen register/trap-and-trace order, national-security request, civil investigative demand, regulator inquiry, PSAP request, traceback request, or law-enforcement request involving Carrier Data, unless legally prohibited.
Processor shall not produce Carrier Data unless:
a. Carrier authorizes production;
b. Processor is legally compelled to produce; or
c. emergency circumstances require disclosure to prevent death or serious physical harm.
Processor shall use reasonable efforts to redirect requests to Carrier where Carrier is the service provider of record.
Processor shall preserve confidentiality of lawful-intercept matters and ensure that only authorized personnel can access lawful-intercept systems or records.
Where Processor provides CALEA-supporting systems, Processor shall support Carrier’s lawful capability requirements, secure audit records, minimization, isolation, delivery, and confidentiality obligations. CALEA requires telecommunications carriers to ensure covered equipment, facilities, and services can isolate and enable lawful interception and access to call-identifying information while protecting non-authorized communications, privacy, security, and the confidentiality of interception activity. (Legal Information Institute)
21. Assistance With Consumer, Subscriber, Carrier, and Regulator Rights
Processor shall assist Carrier in responding to:
a. CPNI disclosure requests;
b. privacy access, deletion, correction, opt-out, appeal, and portability requests;
c. subpoena and litigation-hold requests;
d. regulator inquiries;
e. billing disputes;
f. traceback investigations;
g. erroneous call/text blocking complaints;
h. SIM-swap, port-out, account-takeover, and fraud complaints;
i. E911 complaints or PSAP inquiries; and
j. security questionnaires, audits, and certifications.
Processor shall respond to routine assistance requests within five business days and urgent telecom/regulatory requests within the timeline specified by Carrier, including same-day or 24-hour response where required for traceback, E911, security, or breach matters.
22. Audit, Assessment, and Evidence
Processor shall provide Carrier, at least annually and on request:
a. SOC 2 Type II, ISO 27001, PCI DSS, penetration test summary, or equivalent independent assessment where available;
b. security policies and summaries;
c. vulnerability-management summaries;
d. incident-response plan summary;
e. business-continuity and disaster-recovery summary;
f. Subprocessor list;
g. data-flow diagram for Carrier Data;
h. retention schedule;
i. CPNI training evidence;
j. access-control evidence;
k. breach and incident summary;
l. regulatory compliance attestations relevant to the services; and
m. remediation status for material findings.
Carrier may conduct reasonable audits or appoint a qualified assessor, subject to confidentiality, reasonable notice, and security restrictions. Processor may satisfy routine audits by providing independent reports unless Carrier has a regulator request, unresolved material issue, Security Incident, or reasonable suspicion of noncompliance.
23. Data Quality, Integrity, and Billing Evidence
Processor shall implement controls to ensure integrity, completeness, and accuracy of CDRs, SDRs, IPDRs, SMPP delivery receipts, SIP response codes, rating records, mediation files, billing records, routing logs, number inventory, campaign records, E911 records, consent records, and fraud/blocking records.
Processor shall not modify regulated logs, timestamps, source/destination identifiers, delivery statuses, call dispositions, message states, or billing records except through documented, auditable correction procedures.
Processor shall retain audit trails for manual adjustments, rerates, disputes, credits, refunds, and route overrides.
24. Service Continuity and Resilience
Processor shall maintain disaster-recovery and business-continuity plans appropriate to the contracted services and telecommunications criticality.
For services supporting call routing, SMS routing, E911, fraud blocking, STIR/SHAKEN, lawful intercept, rating, billing, AAA, or customer portals, Processor shall define RTOs, RPOs, escalation paths, failover plans, and scheduled test frequency in the applicable order.
Processor shall promptly notify Carrier of outages, degradation, packet loss, queue backlog, DLR failures, bind failures, trunk failures, DNS failures, certificate expiration, route failure, emergency-service degradation, or security events that materially affect Carrier’s services.
25. Return, Deletion, and Transition Assistance
Upon termination or expiration, Processor shall:
a. stop processing Carrier Data except as required for transition, deletion, legal retention, or Carrier’s written instructions;
b. return Carrier Data in a structured, commonly used format;
c. provide reasonable transition assistance;
d. delete remaining Carrier Data from active systems;
e. delete Carrier Data from backups according to normal backup expiration unless legally required to retain;
f. certify deletion; and
g. continue to protect retained Carrier Data under this DPA until deletion.
26. Regulatory Change Management
Processor shall monitor regulatory changes applicable to the services it provides and notify Carrier of material changes that require changes to Processor systems, policies, workflows, APIs, retention, notices, reports, or contracts.
Carrier may issue updated processing instructions to address regulatory changes. Processor shall implement legally required changes within the required regulatory timeline or, if no timeline is specified, within a commercially reasonable period agreed by the parties.
27. Warranties
Processor represents and warrants that:
a. it has authority to enter into this DPA;
b. it will process Carrier Data only as permitted by this DPA;
c. it has implemented and will maintain the required security program;
d. it will not knowingly introduce malware, spyware, backdoors, or unauthorized access mechanisms;
e. it will not knowingly process Carrier Data in violation of Applicable Law;
f. it will maintain required licenses, authorizations, registrations, and certifications for its services; and
g. it will promptly notify Carrier if it can no longer comply with this DPA.
28. Indemnity
Processor shall indemnify, defend, and hold harmless Carrier, its Affiliates, officers, directors, employees, customers, and agents from third-party claims, regulator actions, fines, penalties, costs, damages, and expenses arising from Processor’s breach of this DPA, unauthorized processing, Security Incident caused by Processor’s failure to meet this DPA, unlawful sale or disclosure of Carrier Data, or Subprocessor acts or omissions.
Carrier shall indemnify Processor from third-party claims arising from Carrier’s unlawful instructions, provided Processor complied with this DPA and promptly notified Carrier if it reasonably believed an instruction violated Applicable Law.
29. Limitation of Liability
The parties may negotiate liability caps in the main agreement. However, the following should be excluded from any general cap unless expressly agreed by Carrier:
a. unauthorized sale or monetization of Carrier Data;
b. intentional misconduct or gross negligence;
c. breach of confidentiality;
d. CPNI misuse;
e. message content or call content disclosure;
f. location or E911 data misuse;
g. unlawful AI training;
h. data-broker disclosure;
i. Security Incident caused by failure to maintain required safeguards;
j. Subprocessor breach;
k. regulatory fines caused by Processor’s breach; and
l. indemnity obligations.
30. Survival
Processor’s confidentiality, security, deletion, audit, breach, cooperation, indemnity, and regulatory-assistance obligations survive termination for as long as Processor retains Carrier Data or as required by Applicable Law.
Annex A — Processing Details
Subject Matter: Provision of telecommunications, messaging, IP-enabled voice, numbering, routing, fraud, analytics, hosting, support, OSS/BSS, billing, mediation, compliance, or related services.
Duration: Term of the services plus retention period in the order, unless longer retention is required by law, litigation hold, fraud investigation, billing dispute, tax obligations, or regulator order.
Purposes: Service provisioning, routing, termination/origination, messaging delivery, DLRs, call completion, E911, customer support, trouble tickets, fraud prevention, spam/abuse control, compliance, billing, settlement, dispute resolution, reporting, analytics authorized by Carrier, security, and lawful requests.
Categories of Data Subjects: Subscribers, end users, enterprise customers, resellers, carriers, employees, agents, business contacts, authorized users, calling parties, called parties, message senders, message recipients, emergency callers, account owners, administrators, and support contacts.
Categories of Carrier Data: Account data; CPNI; call detail records; SMS detail records; IPDRs; SIP headers and logs; SMPP PDUs and logs; message content where processed; sender IDs; short codes; toll-free numbers; 10DLC campaign data; DIDs; MSISDNs; IMSIs; ICCIDs; IMEIs; eSIM profiles; SIM-change records; porting records; E911 registered and dispatchable locations; ANI/pANI; ALI/LIS data; authentication data; consent records; DNC/suppression records; KYC/KYB records; fraud scores; traffic analytics; route tables; rate decks; billing data; tickets; recordings where applicable; lawful-request records; and security logs.
Sensitive Categories: CPNI; location data; emergency-service data; message/call content; authentication credentials; government identifiers; payment data; children’s data if present; health-related messages if present; biometric/voiceprint data if present; lawful-intercept data; and regulated financial information if present.
Retention Defaults: Message content: shortest feasible period, default 0–30 days unless service requires longer. SMPP/SMS metadata and DLRs: 12–24 months unless billing/dispute needs longer. CDRs/IPDRs: 18–36 months unless billing, tax, or legal requirements require longer. Consent/DNC/suppression: duration of campaign plus limitations period. E911 records: per Carrier policy and applicable emergency-service requirements. Security logs: 12–24 months, with hot searchable logs for at least 90 days where feasible. KYC/KYB: account life plus legal retention period. Backups: normal backup cycle, not to exceed the agreed backup retention period.
Annex B — Minimum Security Controls
Processor shall maintain the following baseline controls unless the order imposes stricter controls:
1. MFA for production, admin, VPN, cloud, database, CI/CD, ticketing, and support access.
2. SSO and role-based access where feasible.
3. Least privilege and quarterly access reviews.
4. Encryption in transit using TLS 1.2+ or equivalent; TLS 1.3 preferred.
5. Encryption at rest for databases, object storage, backups, laptops, and removable media.
6. Secrets stored in a secrets manager, not in code or tickets.
7. Centralized logging for access, admin actions, API calls, SMPP binds, SIP trunks, database queries, route changes, billing changes, and security events.
8. Immutable or tamper-evident logs for regulated workflows.
9. Vulnerability scanning at least monthly for external assets and quarterly for internal assets.
10. Critical vulnerability remediation within 15 days, high within 30 days, unless risk-accepted by Carrier.
11. Annual penetration test for internet-facing and Carrier Data systems.
12. Secure SDLC, dependency scanning, SAST/DAST where applicable.
13. Change management for production, routing, rating, E911, and security changes.
14. Network segmentation between tenants, environments, and management planes.
15. Production data not used in non-production unless masked, tokenized, or approved.
16. Secure backups with periodic restoration testing.
17. Incident-response tabletop at least annually.
18. Phishing-resistant MFA for privileged users where feasible.
19. Security awareness training annually and CPNI training for personnel with CPNI access.
20. Documented vendor risk management and subprocessor review.
21. Endpoint protection and EDR for workstations and servers where feasible.
22. Physical access controls for offices and data centers.
23. Secure disposal of paper and electronic media.
24. Data minimization and retention automation.
25. Break-glass access controls with logging and post-approval review.
NIST CSF 2.0 may be used as a control-mapping framework because it provides a cross-sector taxonomy for managing cybersecurity risk; NIST SP 800-61 Rev. 3 may be used for incident-response program alignment. (NIST)
Annex C — Telecom Regulatory Crosswalk
| Area | Contractual Control |
|---|---|
| 47 U.S.C. § 222 / CPNI | Sections 4, 6, 7, 8, 12, 18, 22 |
| FCC CPNI approval, training, records, annual certification | Sections 7, 12, 22 |
| FCC CPNI authentication and account-change safeguards | Section 8 |
| CMRS SIM/eSIM fraud safeguards | Section 8 |
| FCC breach notification readiness | Section 19 |
| TCPA consent, DNC, opt-out, robotext controls | Section 9 |
| Robocall mitigation, traceback, KYC/KYB | Section 10 |
| STIR/SHAKEN and call authentication support | Section 10 |
| E911 / NG911 / VoIP location | Section 11 |
| CALEA / lawful requests | Section 20 |
| GLBA Safeguards where financial data is in scope | Sections 13, 19, 22 |
| State privacy processor/service-provider terms | Sections 4, 5, 6, 15, 18, 21, 22, 25 |
| SMPP/SMS regulated metadata and content | Sections 1, 14, Annex A |
| SIP/CDR/IPDR integrity and billing evidence | Sections 14, 23 |
| AI/model/data-broker restrictions | Sections 6, 17 |
Optional Rider — Mutual Carrier-to-Carrier Data Exchange
Use this rider when both parties act as carriers, interconnected VoIP providers, SMS aggregators, messaging hubs, roaming partners, numbering partners, or wholesale providers.
Each party is an independent controller/carrier for data it processes for its own regulated services, except where one party expressly processes Carrier Data solely on behalf of the other.
Each party shall:
a. use the other party’s proprietary carrier information only to provide the interconnection, routing, settlement, fraud-prevention, regulatory, or support services for which it was disclosed;
b. not use the other party’s customer, reseller, route, rate, traffic, or CPNI information for its own marketing;
c. protect the other party’s proprietary information under 47 U.S.C. § 222 and comparable confidentiality duties;
d. exchange traceback, fraud, emergency, lawful-request, billing-dispute, and security information only for permitted purposes;
e. preserve call/message path data sufficient for regulatory and dispute response;
f. not disclose the other party’s traffic, customers, routes, rates, or counterparties to unauthorized third parties; and
g. notify the other party of Security Incidents involving exchanged data within 24 hours.
References
- eCFR :: 47 CFR 64.2009 -- Safeguards required for use of customer proprietary network information.
- eCFR :: 47 CFR Part 64 Subpart U -- Privacy of Customer Information
- eCFR :: 47 CFR 64.2010 -- Safeguards on the disclosure of customer proprietary network information.
- eCFR :: 47 CFR 64.1200 -- Delivery restrictions.
- eCFR :: 47 CFR 64.6305 -- Robocall mitigation and certification.
- eCFR :: 47 CFR 9.11 -- E911 Service.
- eCFR :: 16 CFR Part 314 -- Standards for Safeguarding Customer Information
- eCFR :: 47 CFR 64.2011 -- Notification of customer proprietary network information security breaches.
- Federal Register :: Data Breach Reporting Requirements

