Skip to main content

Organisational Roles and Responsibilities

Structure and scope​

SbD-ToE defines 17 organisational roles with specific responsibilities linked to the technical chapters and to regulatory obligations (NIS2, DORA, GDPR). Each role is documented with User Stories mapped to the chapters where it is involved.

A role is a set of responsibilities, not a person. One person may hold several roles; the only restrictions on who holds them are the incompatibilities (for example, whoever writes a change does not approve it, and whoever requests an exception does not approve it). The formal list — roles, aliases, specialisations, composites and incompatibilities — is kept as data in this folder (_roles.yaml) and is the source the knowledge graph reads.

Assignment Principles​

Existing Activities, Formalised​

The activities prescribed in the SbD-ToE formalise processes that already exist:

  • Vulnerability remediation → Developer role
  • Validation of security criteria → QA role
  • Prioritisation of security requirements → Product Owner role
  • Pipelines with security controls → DevOps role

The Manual typifies these activities for traceability and regulatory compliance.

Structural Flexibility​

Role assignment varies by organisation. Several roles may be concentrated in one person, or distributed across specialised teams. The SbD-ToE requires the activities to be carried out; it does not prescribe an organisational structure.

The 17 Roles​

📋 Roles Covered​

Each role has its own detailed document with:

  • Description of the role and general responsibilities
  • Specific activities per chapter of the Manual
  • Regulatory framework (NIS2, DORA, GDPR, AI Act)
  • References to the lifecycles where those activities are detailed

Technical roles:

Product and management roles:

Security and governance roles:

Other domains of the organisation (the Manual says what must exist, not how they work):

Third parties:

Each Role Includes​

  • Primary responsibility and scope of action
  • Regulatory framework (NIS2, DORA, GDPR, ISO, NIST)
  • User Stories per chapter
  • Links to the technical chapters
  • Coverage metrics

Note: composite functions (operational, not canonical)​

In organisations with significant adoption of AI agents with tool-use in the SDLC (autonomy levels A2+, see Ch. 02), the need naturally arises to operate the risk specific to those agents — mandates, intent events, kill-switches, agentic telemetry, prompt injection in production, provider drift.

No new canonical role is created for this. Instead, a composite function is recognised — informally called "AI Reliability Engineer" — which combines, in proportions that vary with the organisation, three of the roles already defined:

  • AppSec Engineer — agentic threat modelling, validation of mandates, review of intent events, response to off-policy actions
  • DevOps / SRE — provisioning of workload identity for agents, operational kill-switch, telemetry sinks, kill-switch drills
  • GRC / Compliance — regulatory compliance of the mandates (AI Act, GDPR), A3/A4 approval, periodic audit of the register

The function operates under an explicit mandate from the CISO (or equivalent) that delimits what this function may decide without escalating, and it keeps the canonical roles unchanged — preserving the stability of the SbD-ToE ontology and its compatibility with what has already been written in the Manual and in the academic papers that cite these roles.

🧭 In one sentence: organisations mature in agents need this function; the Manual does not need to typify it as a new role. It is combined from the canonical roles.