Annex B specifies ten roles, each with its responsibilities and key competencies, which the project fills with the independence of 5.1 and the competence evidence of 5.2: requirements manager (Table B.1: owns the software requirements specification, establishes and maintains traceability to and from the system requirements, ensures the requirements sit under change and configuration control recording state, version and authorisation status, ensures consistency and completeness with respect to the user requirements and the final environment; competent in requirements engineering, the application domain and its safety attributes, the system's overall role and environment, analytical techniques, the regulations and this standard), designer (B.2: architecture and design), implementer (B.3: executable code from the design), tester (B.4: component and overall software tests), verifier (B.5: verification of documents, files and processes), integrator (B.6: integration of tested components to the complete software), validator (B.7: judgement on whether the software is valid, with release authority at SIL 3 and 4), assessor (B.8: independent judgement on achievement of the SIL), project manager (B.9) and configuration manager (B.10: configuration and the software version documents). Each role specification requires knowledge of the application domain and the regulatory framework; one person may hold several roles within the independence rules; the roles a document is written by and verified by are in Annex C.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.