Responsibilities lets an administrator name who holds each role in the organisation - CISO, CTO, data protection officer, risk manager, head of IT operations, HR lead and so on - and lets Venvera do the routing from there. Every framework requirement is assigned to the role responsible for it, evidence requests and reminders go to that person, and when a role changes hands the work moves with it. Nobody hand-assigns a thousand requirements.
Naming role holders and watching ownership, evidence requests and reminders follow. (65 seconds)
The roles
Venvera ships eighteen roles in four groups. Each role has a fallback chain, used when the role is empty, so a small team can fill four or five roles and still have every requirement land with a real person.
| Group | Role | Owns | Falls back to |
|---|---|---|---|
| Leadership | CEO / managing director | Ultimate accountability; signs off risk appetite and major policies. | - |
| Management body member | Board-level oversight of ICT and cyber risk (DORA Art. 5, NIS2 Art. 20). | CEO | |
| CISO / head of information security | The security programme: governance, incident response, security architecture, protective controls. | CTO, then Head of compliance | |
| CTO / CIO | Technology strategy, architecture and engineering. | CISO | |
| Governance | Head of compliance | Regulatory obligations, policy lifecycle, audits, reporting to supervisors. The universal fallback for governance requirements. | CISO, then DPO |
| Risk manager / CRO | Risk register, risk assessments, KRIs, the ICT risk-management framework. | Head of compliance, then CISO | |
| Data protection officer | GDPR and NDPA: records of processing, DPIAs, data-subject requests, breach notification. | Head of compliance, then Legal counsel | |
| Internal audit | Independent assurance: audit plans, findings, follow-up. | Head of compliance | |
| Legal counsel | Contracts, data-processing agreements, regulatory interpretation. | Head of compliance | |
| Technology | Head of IT operations / infrastructure | Servers, networks, cloud, backups and disaster recovery; collects infrastructure evidence such as DR test results and patch reports. | CTO, then CISO |
| Security operations lead | Monitoring, logging, vulnerability management, detection and response. | CISO, then IT operations | |
| End-user support lead | Endpoints, user accounts in practice, joiner / mover / leaver execution. | IT operations | |
| Head of engineering / secure development | Secure development lifecycle, code security, change management, product vulnerabilities. | CTO, then IT operations | |
| Operations | Business continuity lead | Continuity plans, impact analysis, DR exercises, crisis management. | IT operations, then Risk manager |
| Third-party / vendor risk lead | Supplier due diligence, contracts, register of information, concentration risk. | Head of compliance, then Risk manager | |
| HR lead | Screening, onboarding and offboarding, training records, disciplinary process. | Head of compliance | |
| Facilities / physical security | Physical access, environmental controls, equipment security. | IT operations | |
| Finance lead / CFO | Financial controls, capital and solvency requirements, outsourcing budgets. | CEO, then Head of compliance |
Every chain ends at the Head of compliance and then the CISO. If those are empty too, the requirement goes to the organisation's first administrator, so nothing is ever left without an owner. Pick a deputy for a role to record who stands in for the holder; routing follows the holder and the fallback chain.
How requirements are routed
Each requirement in the unified requirement store carries the category its framework gives it - "Business Continuity", "Access Control", "Supplier Relationships", "Records of Processing" and so on. Venvera matches that category against an ordered set of rules and hands the requirement to the matching role:
| Category looks like | Goes to |
|---|---|
| Third-party, supplier, supply chain, outsourcing, vendor | Third-party / vendor risk lead |
| Continuity, backup, recovery, disaster, contingency | Business continuity lead |
| Incident, breach, incident response | Security operations lead |
| Logging, monitoring, detection, audit and accountability, vulnerability, security testing | Security operations lead |
| Physical, environmental, facilities | Facilities / physical security |
| Human resources, personnel, awareness, training, screening, remuneration | HR lead |
| Data protection, privacy, data subjects, records of processing, consent, transfers | Data protection officer |
| Endpoints, devices, workstations, mobile, malware | End-user support lead |
| Identity, access, authentication, authorisation, segregation of duties | Head of IT operations |
| Network, firewall, communications, transmission, cloud | Head of IT operations |
| Secure configuration, patching, security updates, media, maintenance, IT operations | Head of IT operations |
| Development, acquisition, change, secure development, software, product security | Head of engineering |
| Risk assessment, risk management, ORSA | Risk manager |
| Internal control, internal audit, performance evaluation, assessment and authorisation | Internal audit |
| Governance, leadership, strategy, policy, compliance, planning, documentation | Head of compliance |
A few frameworks override the category rule because their whole logic belongs to one office. GDPR and NDPA requirements go to the data protection officer unless they are technical security clauses, which go to the CISO. Solvency II routes ORSA and risk clauses to the risk manager, outsourcing to the vendor risk lead, continuity to the business continuity lead, internal control to internal audit, remuneration and fit-and-proper to HR, and the rest to the head of compliance. MiCA splits between the risk manager and the head of compliance. The EU AI Act sends monitoring and IT-general clauses to engineering and the rest to compliance. The Cyber Resilience Act sends secure development and product clauses to engineering, incident and vulnerability handling to security operations, and third-party clauses to the vendor risk lead.
What happens once roles are filled
Click Assign owners now, or wait for the nightly run. Every requirement without an owner gets the resolved role holder as its owner and is marked as assigned by role. Owners you set by hand are never touched.
Each person who received requirements gets one notification with a link to their controls, not one message per requirement.
The evidence autopilot sends renewal and collection requests to the requirement's owner first, then to the domain contact, then to governance. With roles filled, the DR test report is requested from the IT operations lead and the training records from HR without any per-control setup.
Holders of the CEO, board member, CISO, CTO, head of compliance, risk manager and DPO roles are mirrored into the compliance officers register used by reports and regulatory submissions.
When a holder changes, every requirement that was assigned by role re-routes to the new holder on the next run. Requirements with a manual owner keep it.
The two cards at the top show how many roles are filled and how many requirements have an owner, with the share assigned by role. Each role row shows the number of requirements routed to it and whether they are routed directly to a named holder or reach it through a fallback. Keep ownership in sync nightly controls the nightly run; leave it on unless you want assignment to happen only when you click the button.