Security Focus Areas and the Process for Each
Last updated 12 Oct 2026
At a glance
An index of the security-related focus areas an operator has to cover, grouped under the three pillars (privacy, cybersecurity, telecom regulatory compliance), with the process each one calls for and what that process leaves behind. A map for knowing which conversation to start, not a manual for having it.
The picture
How it works
17.1 gave the chain and 17.2 the boundaries. Here each focus area is reduced to the process to follow and what it produces. If nothing was produced, the process did not happen.
Privacy: GDPR and ePrivacy
| Focus area | Process to follow | What it produces |
|---|---|---|
| Personal data processing | DPIA (Art. 35) before high-risk processing begins; RoPA entry (Art. 30) for every processing activity | Signed-off DPIA; a current record of processing |
| Data flows and third parties | 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 | Data classification; masking or pseudonymisation in non-production; a retention and deletion schedule that reaches every copy | Deletion proven in the lake, ticket history and vendor backups |
| Consent and communications data | Lawful-basis assessment per purpose; consent management; ePrivacy rules for traffic and location data | Consent records; logged access to traffic and location data |
Cybersecurity: NIS2
| Focus area | Process to follow | What it produces |
|---|---|---|
| Risk | Risk assessment and threat modelling, repeated on every architecture change | Risk register; exceptions with an owner and an expiry |
| Identity and access | Joiner / mover / leaver; periodic access review; PAM for the management plane | Access review records; PAM session logs; no shared or unexpiring credentials |
| API and integration security | API security review at design time: authentication, authorisation, rate limits, mTLS; gateway policy as code | An API register with a reviewed security profile per API |
| Vulnerabilities | Vulnerability management with patch targets by severity; penetration testing of exposed channels and APIs | Scan coverage; pen-test findings with remediation dates |
| Incident response | IR plan and playbooks; tabletop drills; NIS2 notification: early warning within 24 hours, notification within 72 hours, final report within a month | Drill records; notifications filed within the deadlines |
| Supplier security | Supplier security assessment before onboarding; contractual terms; a register of privileged supplier access | Supplier access reviewed like any other privileged identity |
| Business continuity | BCP / DR planning; restore tests actually performed | A restore record, not a restore assumption |
| Secure change | Security and privacy review in architecture governance and change management (GDPR Art. 25) | A review record per significant change |
Telecom regulatory compliance: EECC
| Focus area | Process to follow | What it produces |
|---|---|---|
| Network and service security | Security measures documented per service, mapped onto the NIS2 control framework | One measure set that satisfies both regimes |
| Resilience and continuity | Continuity planning and availability recording against the obligations | Availability records; tested continuity plans |
| Lawful obligations on communications data | The national-law process for lawful interception and retention, with access strictly controlled and audited | Controlled, logged access the regulator can inspect |
| Regulatory reporting | Incident notification to the regulator; periodic compliance reporting | Reports filed on time |
Two processes that are often confused
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.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Record of processing activities (RoPA) and DPIAs | Privacy management or GRC tool, owned by the DPO | — | Architecture, system owners | Goes stale whenever a new data flow is built without a review. |
| Consent records and marketing preferences | CRM consent store / consent management platform | Digital channels, care agents | Marketing platforms, billing | Downstream systems read consent; they should not hold their own version of it. |
| Risk register and control framework | GRC tool | — | Security architecture, system owners | One control set, with NIS2, EECC, GDPR and ePrivacy mapped onto it. |
| Access rights and access-review records | IAM platform (identity governance) | — | PAM, each application | Includes supplier accounts, which are privileged identities like any other. |
| Security incident records | Security incident or case management (often SIEM/SOAR or ITSM) | — | SIEM, regulator notification record | The clock for NIS2 notification starts here, so timestamps matter. |
| Evidence for regulators | GRC tool / evidence store | — | DPO, security operations, network operations | Drill records, restore tests, pen-test findings, filed notifications. The record set should exist before it is asked for. |
In practice
The most common failure in this area is two parallel compliance programmes, typically privacy under the DPO and NIS2 under security, producing two versions of the same control and two evidence sets. NIS2 and the EECC both ask for network and service security; ePrivacy and GDPR both ask for protection of communications data. Overlap is the norm, not the exception.
The processes that slip first in a busy delivery programme are the ones that leave evidence only when done properly: restore tests, access reviews and deletion that reaches every copy. Deletion is the hardest in an old estate, because personal data has been copied into data lakes, ticket histories, test environments and vendor backups that were never on the data-flow map.
The trade-off
What it solves
Coverage. Each focus area has a named process and a named output, so a programme can see which conversations have not started and which have no evidence behind them.
What it does not solve
- Doing the processes well; the index says a DPIA is needed, not how to write a good one.
- National variation in lawful interception and retention law.
- Legacy data copies that nobody has mapped yet.
What it adds
- A common control framework needs an owner with authority across privacy, security and regulatory teams.
- Mapping each regulation onto shared controls is ongoing work as regulations and the estate change.
- Evidence has to be produced continuously, which means process change in operations, not just documents.
Architecture decision
Run privacy, cybersecurity and telecom compliance as separate programmes, or as one control framework with one evidence store?
One framework, one evidence store
Choose when the same systems and data are in scope of several regulations, which for a BSS/OSS estate is almost always.
Separate programmes, mapped afterwards
Choose when organisational ownership is split and cannot be merged yet, and there is a funded plan to map both onto one control set.
Breaks if the separate programmes are never mapped together. Each assumes the other covers the shared controls, and the regulator finds the gap.
Takeaways
Key Takeaways
- Three pillars, a fixed list of focus areas under each, and for every focus area a named process.
- Every process leaves something behind. If nothing was produced, the process did not happen.
- A DPIA and a NIS2 risk assessment are different processes; one does not satisfy the other.
- One control framework, one evidence store, every regulation mapped onto it.
Check yourself
A programme launches location-based analytics on customer data. Which processes must run before it goes live?Show answerHide
A DPIA, because it is high-risk processing of personal data; a RoPA entry; a lawful-basis assessment and ePrivacy handling for location data; and a security and privacy review through architecture governance. The data-flow map should gain the new copies.
The security team says the DPIA for a new CIAM covers the NIS2 risk assessment. Is that right?Show answerHide
No. The DPIA assesses privacy risk to individuals; the NIS2 risk assessment assesses risk to networks and services. Both are needed, and both should map onto the same control framework.