Epic's security model is built around security groups — sets of permissions that control what each user can see, do, and access within the system. Every user belongs to one or more security groups. Every action in Epic — viewing a policy, editing a client record, running a report — is controlled by those permissions.
Most agencies set up their security groups once, during initial implementation, and never revisit them. The result is a security model that doesn't match how the agency actually operates today.
Common Security Group Problems
- Everyone has admin-level access because it was "easier" during setup
- Security groups haven't been updated to reflect new roles or organizational changes
- Staff can access — and accidentally modify — data they shouldn't be touching
- Report access isn't restricted appropriately for different roles
Why This Matters Beyond Security
The most important reason to get security groups right isn't actually security in the traditional sense — though that matters too. It's data integrity. When the wrong person can accidentally edit a policy record, change a code, or delete an activity, your data gets corrupted in ways that are hard to detect and harder to fix.
The Right Approach
Security group design should start with a role map — a clear picture of who does what in your agency, what data they need access to, and what actions they should and shouldn't be able to take. From there, you build security groups that match those roles, test them, and train staff on why the restrictions exist.
It's not a one-time project. As your agency grows and roles change, your security model needs to keep pace.