Compliance
Configuration compliance for service providers
Hold a national, multi-vendor estate to one policy standard, and prove it to auditors continuously, not reconstructed at audit time.
core-lhr-0000 ·Cisco ·CIS-1.1 DRIFT
- CHECKED
- 148,200
- CONTROLS
- 240+
- VENDORS
- 12
- DRIFT
- 0 open
COMPLIANCE PROOF
A service-provider estate, held to one policy standard and proven continuously, not reconstructed at audit time.
- 100%
- of collected configs policy-checked
- 24/7
- continuous checking
- 1
- estate-wide policy standard
- 0
- silent changes
every device, every collection
on change, not at audit time
across every region and vendor
every change captured and attributed
Figures describe how rConfig operates; deployment-specific results are published with customer permission.
The challenge
Prove it continuously, not at audit time
For a service provider, compliance is a permanent state the network has to hold and the business has to prove. A national, multi-vendor estate drifts constantly: thousands of changes a week, dozens of engineers, and regulators who expect one consistent standard across all of it.
The expensive failure mode is audit-time archaeology: reconstructing months of change to answer a question that should already have an answer. rConfig inverts that, measuring every config against policy as it is collected, so the evidence exists before anyone asks for it, proven at the scale of a Tier 1 ISP estate.
- A policy result for every config, every collection
- Drift events, timestamped and diffed
- Change attribution: who, what, where, when
- An exportable evidence trail for the regulator
How it works
Continuous compliance
The controls a carrier has to demonstrate, running automatically across the whole estate rather than a sampled subset at audit time, the same estate covered in managing 100,000 network devices.
POLICY
Continuous policy checks
Every collected config is checked against policy on every collection, not sampled once a quarter. CIS benchmarks, regulatory controls, and your own internal standards run as code against the whole estate.
Learn moreDRIFT
Drift detection on change
A config that moves out of policy is flagged the moment it changes, with the exact diff and the line that broke compliance. Silent drift stops being something you discover during an audit.
Learn moreACCESS
RBAC and segregation of duties
Role-scoped access, change approval, and separation of duties, the controls auditors look for first. Who can see, who can change, and who signs off are enforced, not documented in a policy nobody reads.
Learn moreAUDIT
Full, exportable audit trail
Who changed what, where, and when, captured for every device and every change. Evidence is already assembled when the auditor asks, instead of reconstructed from memory and scattered logs.
Learn moreREMEDIATE
Remediation and rollback
When a config breaks policy, push the fix or roll back to the last compliant version in a controlled change, with the action captured for the audit trail. Drift gets closed, not just logged.
Learn moreASSIST
Read-only AI that explains findings
Read-only, grounded AI helps triage and explain compliance findings in plain language, so an engineer understands why a config failed faster. Assistive today, never an unattended change to production.
Learn more
The AI assistance above is deliberately read-only today. For where it goes and where it stops, see the network AI maturity model.
Independence
Compliance across every vendor
A standard that only holds on one vendor's kit is not a standard. A service-provider estate is multi-vendor by necessity, and compliance has to span all of it: the current core, the inherited edge, and whatever the next acquisition brings in. Because rConfig sells no network hardware, its neutrality is structural, and policy checks, drift detection, and audit run the same way across every platform. See multi-vendor configuration management for how that neutrality is built.
Frameworks
The regimes your network is in scope for
A service provider's network configuration sits inside sector-specific security regulation. rConfig does not make you compliant; it produces the continuous configuration control and evidence those regimes require, mapped to the standard you are held to.
United Kingdom
The Telecommunications (Security) Act 2021 places overarching security duties on public telecoms providers, with specific measures in the Electronic Communications (Security Measures) Regulations 2022 and the Telecommunications Security Code of Practice, overseen by Ofcom. They cover network architecture, access control, monitoring, and remediation, all of which turn on configuration, and the evidence they expect is what rConfig captures on every collection.
European Union
NIS2 brings electronic-communications and other essential-service operators under stronger network and information security obligations, with configuration security, change control, and incident readiness among them. See NIS2 compliance.
United States
US carriers map configuration and security posture to NIST: the Cybersecurity Framework (CSF 2.0) for governance, and the NIST SP 800-53 Configuration Management controls for baselines, change control, and component inventory, alongside the FCC's CSRIC best practices and CISA's cross-sector Cybersecurity Performance Goals for the communications sector.
Across all of them, benchmark and internal-standard checks, CIS Benchmarks and your own hardening baselines, run as policy against every collected config; see compliance and security auditing.
Providers that also operate in adjacent regulated sectors, financial services under DORA compliance for example, can hold those configuration obligations on the same platform. This page covers what is specific to running compliance at service-provider scale; the generic policy-checking and audit capability lives on the linked solution pages.
Explore the Service Provider hub
- 01Pillarnetwork configuration management for service providersThe Service Provider pillar: positioning and architecture for carrier and ISP estates.
- 02In clusterTier 1 ISP configuration managementBackup, audit, and change control across a ~200k-device estate.
- 03In clustermanaging 100,000 network devicesHow collection and change hold up at six-figure scale.
- 04Solutioncompliance and security auditingAutomated policy checks against CIS and custom internal standards.
- 05SolutionNIS2 complianceMeeting the EU's network and information security directive.
- 06Solutionmulti-vendor configuration managementOne neutral plane across every vendor in the estate.
- 07AInetwork AI maturity modelThe TM Forum L0 to L5 ladder, and the rung rConfig stands on today.
TALK TO US
Make compliance the network's default state
See rConfig prove continuous compliance against a multi-vendor, service-provider estate. Book a working demo, or talk to our team about your audit obligations.
Tell us your device count, vendor mix, and project timeline, and we will map a rollout to your estate.