TRAC: C3.3: Roles, responsibilities, and authorization

C3.3 Repository staff have delineated roles, responsibilities, and authorizations related to implementing changes within the system.

Authorizations are about who can do what—who can add users, who has access to change metadata, who can get at audit logs. It is important that authorizations are justified, that staff understand what they are authorized to do, and that there is a consistent view of this across the organization.

Evidence: ISO 17799 certification; organizational chart; system authorization documentation.

---

ICPSR is a very mature organization, and experiences very low staff turnover and very little of the reorganizations, mergers, and other organizational changes one finds in the for-profit world. Roles and responsibilities are known well, and the knowledge is common across work groups. We don't often hire completely new types of positions, and so when we do hire a new employee, they tend to slot easily into an existing category of employee (e.g., "data processor").

The combination of a category, or role, and the specific work group - such as, the new hire, Jane, is a Data Processor in SAMHDA - translate easily into a set of related technology containers such as Active Directory groups, LDAP groups, old school UNIX /etc/group entries, and even our own custom database that maps people to groups.

My sense is that the net effect is that we have roles that are well understood, but not crisply defined; and we have containers to hold the roles, but those containers are as idiosyncratic as the collection of technology we use to drive ICPSR.