🛡️
Section 15.3
Security Focus Areas and the Process for Each
The focus areas an operator has to cover — personal data, data flows, identity, APIs, vulnerabilities, incidents, suppliers, continuity, regulatory reporting — and the process each one calls for: DPIA, RoPA, risk assessment, access review, penetration test, incident notification.
Sections 15.1 and 15.2 gave the chain and the boundaries. This section is an index: the security-related focus areas an operator has to cover, grouped under the three pillars, and for each one the process to follow and what it leaves behind. It is a map for knowing which conversation to start, not a manual for having it.
1. Privacy — GDPR and ePrivacy
| Focus area | What it is about | Process to follow | What it produces |
|---|---|---|---|
| Personal data processing | Any new or changed processing of customer data — a new CIAM, location analytics, AI on customer records | DPIA (GDPR Art. 35) before high-risk processing begins; RoPA entry (Art. 30) for every processing activity | Signed-off DPIA; a current record of processing activities |
| Data flows and third parties | Where personal data enters, moves, is copied and leaves — CRM, order, billing, logs, backups, analytics, SaaS vendors | Data-flow mapping; a data processing agreement (Art. 28) with every processor; a transfer assessment for data leaving the EEA | Data-flow map with an owner per copy; DPAs on file |
| Data protection in systems | Which fields are personal, sensitive or communications data and how each is handled in production and test | Data classification; masking or pseudonymisation in non-production; a retention and deletion schedule that reaches every copy | Classification on the schema; deletion proven in the lake, ticket history and vendor backups |
| Consent and communications data | Marketing consent, cookies, and the confidentiality of traffic and location data | Lawful-basis assessment per purpose; consent management; ePrivacy rules for traffic and location data | Consent records; logged and reviewed access to traffic and location data |
2. Cybersecurity — NIS2
| Focus area | What it is about | Process to follow | What it produces |
|---|---|---|---|
| Risk | The risks to networks and services, and how an attacker would reach them through this estate | Risk assessment and threat modelling, repeated on every architecture change | Risk register; risks traced to controls; exceptions with an owner and an expiry |
| Identity and access | Customer, workforce, privileged and service-account identities, and what each may reach | Joiner / mover / leaver process; periodic access review; privileged access management for the management plane | Access review records; PAM session logs; no shared or unexpiring credentials |
| API and integration security | Every TMF API and integration between systems — who calls it, how it is authenticated, what it may do | API security review at design time: authentication, authorisation, rate limits, mTLS between systems; gateway policy as code | An API register with a reviewed security profile per API |
| Vulnerabilities | Weaknesses in the estate’s own software and configuration | Vulnerability management with patch targets by severity; penetration testing of exposed channels and APIs | Scan coverage of the BSS/OSS estate; pen-test findings with remediation dates |
| Incident response | Detecting, containing, reporting and recovering from a security incident | Incident response plan and playbooks; tabletop drills; NIS2 notification — early warning within 24 hours, notification within 72 hours, final report within a month | IR plan; drill records; notifications filed within the deadlines |
| Supplier security | Every vendor, SaaS provider and integrator with a path into the estate | Supplier security assessment before onboarding; contractual security terms; a register of privileged supplier access | Assessments on file; supplier access reviewed like any other privileged identity |
| Business continuity | Keeping, or restoring, service when a site, platform or supplier is lost | BCP / DR planning; restore tests actually performed | A tested continuity plan; a restore record, not a restore assumption |
| Secure change | Making sure controls exist in the first version of a flow, not the second | Security and privacy review in architecture governance and change management — security-by-design and privacy-by-design (GDPR Art. 25) | A review record per significant change |
3. Telecom regulatory compliance — EECC
| Focus area | What it is about | Process to follow | What it produces |
|---|---|---|---|
| Network and service security | The operator’s obligations as a provider of electronic communications | Security measures documented per service, mapped onto the NIS2 control framework so there is one control set | One documented measure set that satisfies both regimes |
| Resilience and continuity of service | Availability and recovery of networks and services | Continuity planning and availability recording against the obligations | Availability records; tested continuity plans |
| Lawful obligations on communications data | Lawful interception and data retention under national law, and the confidentiality of communications | The national-law process for each obligation, with access strictly controlled and audited | Controlled, logged access; a record the regulator can inspect |
| Regulatory reporting | Incident notifications and periodic records to the national regulator | Incident notification to the regulator; periodic compliance reporting | Reports filed on time; the record set exists before it is asked for |
One control set, several regulators
NIS2 and the EECC both ask for network and service security; ePrivacy and GDPR both ask for protection of communications data. Build one control framework and one evidence store and map each regulation onto it. Two parallel compliance programmes producing two versions of the same control is the most common failure in this module.
DPIA is not “the security assessment”
A DPIA assesses privacy risk to the individual. The NIS2 risk assessment assesses risk to networks and services. They are two processes in two pillars, and completing one does not satisfy the other.
Key Takeaways
- Three pillars, a fixed list of focus areas under each, and for every focus area a named process — DPIA, RoPA, risk assessment, access review, penetration test, incident notification.
- Every process leaves something behind. If nothing was produced, the process did not happen.
- One control framework, one evidence store, every regulation mapped onto it.