Stakeholder register and engagement procedure

Stakeholder register and engagement procedure

ST-01 — Identify stakeholders

The system owner establishes a stakeholder register before agreeing the system’s needs and keeps it current throughout the life cycle. Identification covers sponsors, acquirers, users, operators, maintainers, developers, suppliers, assessors, decision authorities and people affected by system operation. It includes people whose information is processed and parties who rely on the system’s outputs without directly using it. Organisational teams are represented by a named contact or recorded representation arrangement.

The owner reviews the system boundary, information flows, service dependencies, agreements and intended operating environment to identify missing participants. The register distinguishes a person’s interest from their formal authority. Being affected by the system does not require someone to hold a project role; holding a project role does not establish authority to speak for every affected group.

ST-02 — Stakeholder record

ST-03 — Capture needs and concerns

The responsible analyst asks each stakeholder or representative to describe what they need to accomplish, the conditions in which the system will be used, and what could make the outcome unacceptable. The analyst records the stakeholder’s language before translating it into system requirements. Needs include access to service, timely information, ability to correct errors, protection of confidential information, continuity of essential work and a route for assistance when the system does not behave as expected.

The analyst records the source, context, assumptions and any unresolved ambiguity. A preference, constraint, legal obligation, contractual commitment and proposed solution are identified separately. Where a stakeholder requests a particular implementation, the analyst records the underlying need as well as the requested implementation, without treating either as approved until the relevant authority decides.

ST-04 — Establish protection needs

The owner works with stakeholders to identify the assets, information, services and interests requiring protection. The record describes potential losses in terms meaningful to the affected party, including loss of service, unauthorised disclosure or change, inappropriate processing, financial loss, loss of control over a decision and inability to recover. Dependencies on people, facilities, equipment and suppliers are considered alongside software and data.

For each material loss, the owner records the conditions under which it could occur, the affected stakeholders, the significance of the consequence and any timing sensitivity. Where views differ, the record preserves those differences. An organisational risk score does not replace the description of consequences to people or to another organisation.

ST-05 — Resolve conflicts and validate interpretation

The analyst returns the recorded needs to the relevant participants for confirmation. Confirmation establishes whether the record represents their contribution; it does not necessarily approve a design or accept a risk. Unconfirmed interpretations are marked as such. When stakeholders cannot participate, the owner records the limitation and the basis used for any interim decision.

Conflicting needs are brought to the authority identified for the decision. The decision record states the conflict, the parties consulted, alternatives, consequences and rationale. The resulting requirement links to the source needs and the decision. Dissent and unresolved concerns remain traceable. Silence is recorded as no response, rather than agreement, unless an established agreement explicitly defines a different decision mechanism.

ST-06 — Maintain engagement through delivery

The engagement schedule identifies which stakeholders participate in requirements review, design review, validation, release acceptance, operational review and retirement. The owner uses methods appropriate to the participants, including accessible documents, demonstrations, structured interviews or service feedback. Consultation material explains the decision in terms of system effects and consequences, with technical details available where relevant.

Changes in intended use, data processing, operating conditions, supplier arrangements or system behaviour trigger a review of affected stakeholders. New concerns enter the issue or risk register and are connected to the relevant requirements. The owner communicates decisions and resulting actions through the recorded contact arrangements. Where disclosure must be limited, the record identifies what could be shared and how meaningful participation was maintained.

ST-07 — Evidence and assurance

The custodian retains the stakeholder register, consultation records, confirmed needs, decisions and unresolved issues under the evidence procedure. Personal contact details are accessible to those who need them for the engagement purpose. The public or widely distributed version of a requirements document need not reproduce private contact information; a stakeholder ID can provide the necessary trace.

At [schedule] and before major acceptance decisions, the reviewer checks whether affected parties have been identified and whether their needs are represented in requirements and validation plans. The reviewer follows selected needs from source to decision, implementation and validation evidence. The assessment records whose interests were considered, where representation was limited and which concerns remain open. The owner assigns actions for missing engagement or broken traceability rather than declaring the stakeholder process complete solely because a register exists.