The most effective charity design sessions bring together the people who understand the problem, the people who can judge technical feasibility, and the people who will help turn an idea into a buildable concept. That mix reduces guesswork, exposes constraints early, and increases the chance that the final solution is practical for day-to-day use.
Who needs to be in the room for a charity digital identity design session?
Bring in a small but complete group: the service owner who understands the charity’s user journey, the technical lead who can test what is buildable, and the people responsible for operations, privacy, and support. If the solution will use federation, wallets, or external identity providers, add the relevant delivery and assurance stakeholders early so constraints are visible before decisions harden.
What each participant contributes to the design
The strongest sessions are cross-functional, not purely technical. The service owner brings the real workflow, the technical lead translates it into architecture and integration choices, and operations staff surface the support load, recovery steps, and day-two maintenance that often determine whether a solution survives contact with users. For charities, that mix matters because adoption usually fails when design ignores frontline delivery or the realities of limited internal capacity.
It also helps to include someone who can speak for privacy, safeguarding, and user trust, especially if the charity serves vulnerable people or handles sensitive personal data. If the identity journey involves proofing, login, recovery, or delegated access, those choices affect who can participate, what evidence is collected, and how much friction users will tolerate. A designer can shape the flow, but only the people accountable for the service can judge whether the trade-offs are acceptable.
When the solution depends on a digital identity scheme, the relevant policy or standards view should be present as well. That is where the design can be checked against the practical shape of eIDAS 2.0, the EU Digital Identity Framework, or similar trust assumptions if the charity needs cross-organisation interoperability. The point is not to turn the workshop into a compliance exercise, but to avoid designing around assumptions that later block integration, assurance, or user acceptance.
How to choose the right mix without overloading the workshop
Start with the smallest group that can answer three questions: what problem are we solving, what is feasible to deliver, and what would make the solution safe and usable in practice? That usually means one or two people from the service side, one technical architect or engineer, one operations or support representative, and one person with governance responsibility. If the charity relies on external vendors, volunteer systems, or a partner platform, bring those voices in before the design settles on an approach that cannot be supported later.
Do not make the session a general stakeholder forum. Too many attendees can slow down decision-making and blur ownership, while too few can produce a design that looks elegant but fails operationally. A good rule is to invite the people who can make a decision, challenge a constraint, or commit to the next implementation step. Everyone else can be consulted later, but they should not be required to approve every conceptual choice in the room.
Where the design will affect account lifecycle, access reviews, or handoff between teams, the session should also connect to the broader identity governance picture. Internal planning around NHI lifecycle management helps teams think about ownership, onboarding, change, and offboarding as part of design rather than as a later cleanup task. Even in a charity context, that discipline reduces the chance that a useful pilot becomes a long-term support burden.
Risk and Threat Considerations
Digital identity design creates risk when the wrong people are excluded from the workshop, because the resulting flow can over-collect data, overcomplicate recovery, or leave gaps in support ownership. The main threat is not only external abuse, but also internal misalignment, where a workable concept is approved before anyone has tested how it behaves for real users or real support teams.
Failure mechanism: A narrow design group misses operational constraints, privacy requirements, or escalation paths, so the charity launches a solution that is hard to support, easy to misuse, or impossible to adapt when exceptions arise.
Impact: Users may abandon the journey, support costs may rise, and the charity may inherit avoidable exposure through weak recovery processes, poor access control, or uncontrolled exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PM-5 — System Inventory | Identity design needs clear ownership and lifecycle visibility. |
| AC-2 — Account Management | Design decisions affect account setup, support, and offboarding. | |
| Recommendation — Document identity components and owners before approving the design. Define account lifecycle responsibilities during the design session. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The workshop should shape how access decisions will be governed. |
| Recommendation — Set access governance rules before implementation starts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Charity identity design must account for account lifecycle and ownership. |
| Recommendation — Assign account ownership and review responsibilities early. | ||
Practitioner Guidance
What to prioritise: Put the service owner, technical implementer, and operational owner in the first design session, then add privacy or safeguarding input wherever user data, recovery, or vulnerable users are involved. If the session cannot identify who will own the outcome after launch, the group is too vague to produce a usable design.
What to verify: Before trusting the concept, confirm that the team has covered user journey, implementation constraints, support model, and governance ownership in the same conversation. If any of those are missing, the design is not yet complete enough to move into build.
Practitioner takeaway: The key judgement is not how many stakeholders attend, but whether the room contains the people who can surface real constraints and accept real responsibility for what happens after the design workshop ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
