From Regulation to Evidence
Last updated 12 Oct 2026
At a glance
Security in a BSS/OSS estate is a chain: Regulation → Requirement → Risk → Architecture control → Deliverable → Evidence. This section sets the regulatory scope for a European operator (GDPR, ePrivacy, NIS2, EECC), reduces it to three pillars of work, and shows where the controls land: on the trust boundaries between systems.
The picture
How it works
The chain, read in both directions
Read down, the law creates a requirement, the requirement names a risk in this estate, the risk is met by an architecture control, the control produces a deliverable, and the deliverable is proven by evidence. Read up as well. A control with no regulation or risk above it is a cost nobody owns; a regulation with no evidence beneath it is an audit finding not yet written. Security architecture for a telco is the discipline of keeping that chain intact while the estate changes under it.
The regulatory scope
Four instruments cover most of what a BSS/OSS architect designs for. Public electronic communications providers sit explicitly in NIS2’s high-criticality sectors. GDPR and ePrivacy bite hardest on telcos because of the volume and sensitivity of customer and communications data. The EECC is the sector’s own framework for networks and services.
| Regulation | What it covers | Key BSS/OSS deliverables |
|---|---|---|
| GDPR | Personal and customer data | DPIA, RoPA, data-flow map, privacy-by-design assessment, retention and deletion rules, data-processing agreements |
| ePrivacy | Confidentiality of communications; traffic and location data; marketing; cookies | Communications-privacy assessment, consent mechanisms, retention rules, breach procedures |
| NIS2 | Cybersecurity and resilience of networks and services | Risk assessment, security architecture, control framework, incident response, BCP/DR, vulnerability management, supplier risk, security evidence |
| EECC | Security and resilience of electronic communications networks and services | Network and service security measures, incident management, continuity controls, regulatory records |
National security-of-networks rules, lawful intercept and sector-specific retention law sit on top of these four and vary by member state. They follow the same chain.
Three pillars of work
- Privacy (GDPR, ePrivacy): DPIA, data-flow map, RoPA, data classification, retention and deletion model.
- Cybersecurity (NIS2): risk assessment, threat model, security architecture, controls, vulnerability management, incident response, BCP/DR, supplier security.
- Telecom regulatory compliance (EECC, overlapping NIS2 and ePrivacy): service and network security, resilience and continuity, communications data protection, regulatory reporting.
Each pillar has a fixed set of focus areas, each with the process it calls for: 17.3.
Where the controls land: trust boundaries
The architecture-control rung is enforced at the boundaries between zones of the estate: channels, BSS, OSS, the network management plane. To cross a boundary, something must be authenticated, authorised and logged, and each zone trusts the one above it a little less.
| Principle | What it means here | Which rung it serves |
|---|---|---|
| Trust boundary | A line across which nothing is trusted by default | Architecture control: NIS2 zoning, EECC network security |
| Least privilege | Each identity may do the minimum its job needs | Architecture control: GDPR minimisation, NIS2 access control |
| Zero trust | Every request is verified, wherever it comes from | Architecture control: SOM authenticates COM although both are “inside” |
| Security-by-design | Controls exist in the first version of the flow | Deliverable: privacy-by-design assessment, GDPR Art. 25 |
| Defence in depth | No single control is load-bearing | Evidence: a failed control is detected, not discovered |
The questions to ask at each boundary of the order chain are in 17.2.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Regulatory obligation and requirement register | GRC tool (or the compliance function’s register) | — | Legal / DPO | The top two rungs. Often a spreadsheet in practice; what matters is that each requirement has an owner. |
| Risk register | GRC tool | — | Security architecture | Risks traced to controls, with exceptions that carry an owner and an expiry. |
| Security policy and control framework | GRC tool / security function | — | Each system owner | One control set mapped to all four regulations, not one per regulation. |
| Identities and access rights | IAM platform (workforce and service accounts); CIAM (customers) | Channels, admin consoles | API gateway, PAM | The gateway and each system enforce rights; they should not be where rights are defined. |
| Security audit logs | SIEM / central log store | — | Each system that emits them | Source systems produce the events; the central copy is the one that must be immutable and retained. |
| Evidence for regulators (DPIA, RoPA, test and drill records) | GRC tool / evidence store | — | DPO, security operations | The bottom rung. If it is scattered across team drives, the chain cannot be read upwards. |
In practice
Most operators already hold the pieces: an IAM platform, a SIEM, a GRC or compliance tool, a DPO with a RoPA. What is usually missing is the link between them. Controls are deployed without a recorded risk above them, and evidence is gathered per audit rather than produced as a by-product of operation.
Legacy BSS/OSS estates were rarely built with internal trust boundaries. Systems inside the data centre trust each other by network location, shared service accounts are common, and personal data has been copied into reporting, test and archive stores nobody mapped. Retrofitting boundaries is slower and more expensive than building them in, and it usually surfaces data flows the RoPA does not show.
The trade-off
What it solves
Traceability. Every control can be justified by a risk and a regulation, and every regulation can be shown to have evidence beneath it. That makes security spend defensible and audits predictable.
What it does not solve
- Choosing or configuring the controls themselves; that is specialist security engineering.
- Member-state variation: lawful intercept, national retention and security-of-networks rules sit on top.
- Legacy estates that already trust by network location; the chain shows the gap but does not close it.
What it adds
- Someone has to maintain the mapping between regulations, risks, controls and evidence as the estate changes.
- Internal trust boundaries add authentication, token management and logging to every system-to-system call.
- Overlapping regulations tempt teams into parallel compliance programmes unless one control set is enforced.
Architecture decision
Organise security work per regulation, or as one control framework that every regulation maps onto?
One control framework, mapped to each regulation
Choose when the same estate is in scope of GDPR, ePrivacy, NIS2 and the EECC, which for a European operator it nearly always is.
A programme per regulation
Choose when a single regulation has a hard, near deadline and a narrow scope, and the work will be folded into the common framework afterwards.
Breaks if the per-regulation programmes never merge. The estate then carries two versions of the same control, two evidence sets, and gaps where each programme assumed the other covered it.
Takeaways
Key Takeaways
- Regulation → Requirement → Risk → Architecture control → Deliverable → Evidence: if a link is missing, the design is incomplete whatever the firewall says.
- Read the chain upwards too: a control with no risk above it is unowned cost.
- GDPR, ePrivacy, NIS2 and the EECC set the scope for a European operator and reduce to three pillars: privacy, cybersecurity, telecom regulatory compliance.
- Controls are enforced at trust boundaries between systems; deliverables and evidence prove the other rungs.
Check yourself
A team proposes mTLS between COM and SOM. How do you test whether it belongs in the design?Show answerHide
Trace it up the chain: which risk does it treat (an untrusted caller creating service orders), which requirement names that risk (NIS2 access control and zoning), and which deliverable and evidence it will produce. If no risk or requirement sits above it, it is cost nobody owns.
An auditor asks for proof that personal data is deleted on schedule. Which rung is being tested, and where should the answer live?Show answerHide
The evidence rung. The answer should be a deletion record in the evidence store that covers every copy on the data-flow map, not a policy document describing the intention.