A charity is likely using the wrong process if staff depend on manual recall, people must repeatedly re-enter the same background information, or service records are difficult to reconcile across visits and channels. Another warning sign is when identity checks become a barrier for people without smartphones, documents, or reliable connectivity. Those symptoms usually point to poor fit between the process and the service model.
What tells you the process is a bad fit for the charity’s service model?
The clearest sign is friction that appears at the point where identity should help delivery, not slow it down. If staff are improvising around the process, asking people to repeat the same facts, or stitching records together after the fact, the process is probably optimised for administration rather than service. A good process should support continuity across visits, channels, and staff handoffs.
That mismatch often shows up when the process assumes a stable digital life that the charity’s users do not have. If the process depends on smartphones, reliable connectivity, or documents people cannot easily produce, it is not just inconvenient, it is excluding the very people the charity is trying to serve.
Good fit is less about choosing the most rigorous check and more about choosing the right level of confidence for the service context. The process should capture only the information needed, at the moment it is needed, and in a form staff can actually use to recognise returning people without creating avoidable barriers.
Which operational symptoms usually reveal the wrong process?
One common symptom is repeated manual recall. If frontline staff must remember people by face, by memory, or by informal notes because the process does not preserve a usable identity trail, then the process is failing as a service control. Another symptom is repeated re-entry of background data, which usually means the process is not carrying forward trusted information from one interaction to the next.
Another warning sign is record fragmentation. When service history, eligibility evidence, and contact details cannot be reconciled across visits or channels, the organisation loses continuity and creates duplicate handling. That is a strong sign that the process has become too rigid, too siloed, or too dependent on one-off checks that do not travel with the person.
Equally important is the experience of people who are blocked by the process even though they should be able to access support. If identity checking becomes a barrier for people without a phone, a current address, standard documents, or stable internet, the process is misaligned with the charity’s actual population and likely needs redesign.
What should a charity look for before changing the process?
The right starting point is to distinguish between a weak process and an overcomplicated one. A weak process fails to establish who someone is, while an overcomplicated process creates avoidable effort without improving confidence. If the team cannot explain what the process is protecting, who uses the result, and how often the result is reused, the design is probably unclear.
Charities should test whether the process supports continuity, fairness, and staff judgment together. That means checking whether the same person can be recognised safely across repeat contact, whether staff can resolve mismatches without escalating every case, and whether the process works for people whose circumstances make conventional verification harder.
One practical checkpoint is whether the process produces a usable outcome for service delivery, not just a completed form. If the output cannot help staff avoid duplicate questioning, reduce error, or link records confidently, then it is probably generating compliance theatre rather than operational value. For this kind of problem, Identity Security Programme Guide is useful background on how identity processes fit into a wider operating model.
Risk and Threat Considerations
Identity processes in charities can create both exclusion risk and data quality risk when they are designed around the organisation’s convenience instead of the service user’s reality. A poorly matched process can push people toward repeated disclosure, increase duplicate records, and make it harder to spot the same person across channels, which weakens both service continuity and accountability.
Failure mechanism: The process depends on assumptions that are not true for the user base, such as persistent devices, stable contact details, or documents on demand. That leads to manual workarounds, fragmented records, and inconsistent verification decisions.
Impact: Staff spend more time reconciling identities, users face avoidable barriers, and the charity may either over-verify people who need help or under-verify when it cannot confidently join records together.
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 NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Charity identity processes must balance access and assurance for service users. |
| Recommendation — Design identity steps so access is proportionate to the service need and user context. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns whether the chosen identity process reliably identifies returning users. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Charities often authenticate external service users whose circumstances differ from employees. | |
| IA-5 — Authenticator Management | Repeated re-entry and manual recall often indicate poor handling of identity material or reuse. | |
| Recommendation — Choose an identification approach that matches the users, channels, and assurance needed. Use user-facing identity steps that reflect external users' access patterns and constraints. Manage identity evidence and authenticators so users are not repeatedly asked to re-prove themselves. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | The issue is whether identity handling fits the service model and supports dependable access. |
| Recommendation — Align identity handling with service delivery so access is both reliable and proportionate. | ||
Practitioner Guidance
What to verify: Check whether the process preserves continuity across repeat contact without forcing people to restate core details. If staff cannot confidently explain how the same person is recognised after a second or third visit, the process is not fit for purpose.
Decision rule: If the process requires a smartphone, a fixed address, or documents that part of the target population is unlikely to have, redesign it rather than adding exceptions one case at a time. Exceptions should be rare and intentional, not the primary operating mode.
What good looks like: The best process is one that reduces duplication for staff, keeps service history usable, and still lets the charity apply stronger checks when the risk is genuinely higher. The test is not maximum verification, it is dependable service with proportionate confidence.
Practitioner takeaway: If an identity process makes ordinary service delivery harder, it is probably solving the wrong problem, the right fix is usually to align the process with how people actually access the charity, not to add more steps.
