From Regulation to Evidence
The six-rung chain the module teaches, the four regulations that set a European operator’s scope, the three pillars they reduce to, and the trust boundaries where controls land.
Regulation → Requirement → Risk → Architecture control → Deliverable → Evidence. Every security decision in a BSS/OSS estate should be traceable along that chain in both directions.
Read up as well as down. 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 for a European operator
Four instruments cover most of what a BSS/OSS architect has to design for. Public electronic communications providers sit explicitly in NIS2’s high-criticality sectors; GDPR and ePrivacy form the core EU digital-privacy framework and 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 / data-lineage 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, data-retention rules, breach procedures |
| NIS2 | Cybersecurity and resilience of networks and services | Cyber risk assessment, security architecture, control framework, incident-response plan, BCP/DR, vulnerability management, supplier-risk assessment, security evidence |
| EECC | Regulation, security and resilience of electronic communications services and networks | Network and service security measures, incident management, resilience and continuity controls, regulatory records, customer and service obligations |
Three pillars in practice
In architecture terms the four regulations reduce to three pillars of work. Each pillar has a fixed set of focus areas; section 15.3 lists them and names the process each one calls for.
Where the controls land: the estate as trust boundaries
| 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 |
What this module does not solve
It will not make you a security architect or a privacy lawyer, and it does not list controls. It gives an architect the chain, the questions to ask at each boundary — 15.2 — and the focus areas with the process each one calls for — 15.3.
Key Takeaways
- Regulation → Requirement → Risk → Architecture control → Deliverable → Evidence: if a link is missing, the design is incomplete whatever the firewall says.
- Four regulations set the scope for a European operator — GDPR, ePrivacy, NIS2, EECC — and they reduce to three pillars of work.
- The trust boundaries in the estate are where the architecture-control rung is enforced; the deliverables and evidence are how the other rungs are proven.