How to approach it strategically before changing permissions.
Security isn’t the glamorous part of a CRM implementation. But it’s one of the most defining.
A well-designed security model protects sensitive supporter data, builds trust, reduces admin load, and sets your team up for scalable growth. A poorly designed one creates confusion, bottlenecks, and risky shortcuts.
Too often, security is treated as a technical setup task at the end of a project. In reality, it’s a strategic design choice that shapes how your people work, how data flows, and how your charity demonstrates good governance.
Although this article was sparked by a discussion among charities implementing Microsoft Dynamics, the principles apply to any CRM system eg: Salesforce, Beacon, Raiser’s Edge, ThankQ, or any bespoke database. Whatever platform you use, the thinking is the same: start with people, build around groups, and document your governance clearly.
1. Start with people, not permissions
Before you look at any security settings, take a step back and ask: who are our users, and what do they need to do?
Think in terms of groups of responsibility rather than individuals. It’s easier to manage, easier to audit, and much more scalable.
| Group | Typical Roles | Core Access Needs | Risks if Over-Granted |
|---|---|---|---|
| Read-Only Users | Trustees, auditors, temporary contractors | View records and dashboards, no editing | Data leaks if export rights remain open |
| Normal Users | Fundraisers, service delivery staff, volunteers | Create and update records within their team | Cross-team edits causing errors |
| Super Users | Data champions, team leads | Wider access, bulk edits, report creation | Becoming accidental admins |
| Administrators | CRM or data managers | Configure system settings, users, integrations | Misconfiguration or data loss |
| Super Administrators | IT or external partners | Environment-level control, API keys, backups | Unchecked access, limited oversight |
This five-tier model works in most systems, but it’s not a rulebook. It’s a framework for understanding trust and responsibility.
2. Recognise that people wear more than one hat
One of the most common misconceptions about CRM security is that every person fits neatly into one role. They don’t.
A fundraiser might also support events. A volunteer coordinator might help process donations. The Head of Fundraising might need both campaign data and financial reports.
Good CRM platforms handle this flexibility, users can belong to multiple groups or roles, each layering permissions on top of one another.
That layering allows for hybrid responsibilities, but it demands careful planning:
- Be intentional: overlap roles only where it reflects real-world practice.
- Document every exception: note why someone sits in more than one group.
- Review regularly: as responsibilities change, so should their access.
Think of your security model like an orchestra. Each section (group) plays its part, but some musicians double on instruments when needed. The key is harmony, not chaos.
3. Ask the right questions early
Before building your first permission set, gather your project team and ask:
| Theme | Strategic Questions |
|---|---|
| Governance | Who owns data quality? Who approves access changes? |
| Segmentation | Should fundraising, volunteering, and service teams see the same contacts? |
| Compliance | How will you manage right-to-be-forgotten or access requests? |
| Support | Who trains new users and removes leavers? |
| Auditability | How will you track who changed what and when? |
| Scalability | What happens when the team doubles or restructures? |
| External Access | Will agencies or partners need temporary access, and how will you manage that safely? |
These questions are not about software configuration they’re about your operating model and data culture.
4. Use groups and teams rather than individuals
Whatever CRM you use, permissions can usually be grouped by:
- Role-based access (what someone can do)
- Team or department access (where they can do it)
- Record ownership (whose data it is)
It’s tempting to fine-tune individuals. Resist that urge. Assign access via roles and teams.
The benefits:
- Consistency: people doing the same job have the same rights.
- Efficiency: onboarding and offboarding are quick and reliable.
- Audit clarity: reviewing five roles is easier than reviewing fifty users.
- Future-proofing: structures can evolve without manual rebuilds.
Working with groups also supports your GDPR accountability, it’s much easier to demonstrate that permissions are “appropriate and proportionate” when they’re structured and documented.
5. Document, document, document
Security design decisions need to be written down not left in emails or memory.
| Document Type | Purpose | Maintained By |
|---|---|---|
| Security Model Overview | Summary of groups, roles, and their hierarchy. | CRM Manager |
| Access Matrix | Which group can perform which action (create, read, update, delete). | Data or System Admin |
| Role Assignment Log | Who belongs to which group(s) and why. | HR or IT |
| Access Request Workflow | Defines how access is requested, approved, and removed. | Governance Lead |
| Audit & Review Schedule | Specifies how often access is reviewed (quarterly or bi-annually). | DPO or Data Governance Lead |
You don’t need complex tooling. Even a shared spreadsheet or Confluence page can provide essential traceability.
6. Decision-making and audit
Every change in access should leave a decision trail:
- Request — logged through a form or ticket.
- Approval — authorised by a role owner, not the requester.
- Implementation — applied by a system admin.
- Verification — checked for accuracy and logged.
- Review — included in your regular audit cycle.
Enable your CRM’s audit logging or change history for high-risk entities (contacts, donations, consents).
Key tips:
- Apply the principle of least privilege, grant only what’s necessary.
- Use role rotation or multi-approval for administrator rights.
- Keep a quarterly “access attestation” process where managers confirm team permissions.
Auditing isn’t about suspicion. It’s about building trust and stewardship.
7. When staff are multifaceted just like your supporters
Just as supporters can be donors, volunteers, and campaigners, staff also cross boundaries.
Your security model should reflect this overlap without overcomplicating it.
- Use additive roles: a user in Fundraising Member and Events Coordinator groups inherits both sets of permissions.
- Define ownership clearly: which department owns which data?
- Communicate boundaries: help staff understand where their visibility ends.
- Automate transitions: link HR joiner-mover-leaver processes to your CRM if possible.
Test scenarios that mirror real life:
“What can Jane see if she’s both Fundraising and Comms?”
“What happens when the CEO joins Leadership and Finance groups?”
Good systems handle these overlaps, great governance makes them intentional.
8. Best practice and further reading
Whether you’re using Dynamics, Salesforce, Beacon, or anything else, these resources provide useful guidance:
| Source | Focus | Link |
|---|---|---|
| Microsoft Learn: Security Model Overview | Clear explanation of roles, teams, and layered permissions. | https://learn.microsoft.com/en-us/dynamics365/get-started/security |
| Salesforce Role Hierarchies Guide | Explains layered and team-based security. | help.salesforce.com |
| NCVO Digital Guides | Practical and step-by-step guidance to make the best use of digital tools and processes to help your charity, organisation or community group | https://www.ncvo.org.uk/help-and-guidance/digital-technology/ |
| Information Commissioner’s Office (ICO) | GDPR guidance on access control and data minimisation. | ico.org.uk |
| Actually Data Analytics – Data Quality Framework | Six dimensions of data quality to underpin governance and audit. | actuallydata.net |
Each reinforces the same truth: a strong security model is as much about culture and clarity as it is about configuration.
9. The benefits of getting this right
When your security model is group-based, documented, and layered, you gain:
- Confidence and compliance — roles are auditable and easy to review.
- Reduced admin load — access changes are quick and repeatable.
- Cleaner data — people only edit what they’re responsible for.
- Empowered teams — clarity builds confidence, not constraint.
- Scalability — new functions or systems can slot into the same model.
Most importantly, your CRM reflects your charity’s values: trust, transparency, and good stewardship.
10. Practical next steps
You don’t need a huge project to get started. Begin today with:
- List your user groups using the five-tier model as a foundation.
- Identify overlaps where staff hold more than one hat.
- Document permissions in a simple matrix.
- Create an approval workflow for new access requests.
- Pilot the structure in a test or sandbox environment.
- Train and communicate so everyone understands why as well as what.
- Schedule reviews your structure should evolve with your people.
11. Closing reflection
Security isn’t about locking people out. It’s about letting the right people in! With the right tools, to do the right work, safely.
Charities that design security as a strategic enabler build CRMs that work with people, not against them.
They protect supporter trust, empower staff, and make governance visible.
Whether you use Dynamics, Salesforce, Beacon, or anything else, start with people, define clear groups, and document your decisions. Your future self and your auditors will thank you.
Can we help?
If you’re reviewing your CRM security model or planning a system change, Actually Data Analytics can help you build frameworks that balance access, governance, and agility.
Explore our Data Quality and Governance posts, or sign up for CRAFT Signals to gain access to templates and checklists that strengthen your data foundations for free.