Administration
Users, roles, and Business Unit scope
Administration starts with the principle of least privilege. Permissions are granular capabilities; roles bundle permissions. Assign roles to users within a Business Unit, and remember that a user can have different roles in different Business Units. A parent Business Unit does not automatically grant access to child Business Unit data, and an enterprise-level role is not the same as a BU-level role. Trap: granting Administrator because a user needs one capability. Build a narrow role instead.
Security controls
Account security includes password policies, multi-factor authentication or SSO, IP allowlisting, and session settings. SSO shifts authentication to an identity provider; it does not replace the user's Marketing Cloud roles. Installed packages and API integrations also have scopes. A server-to-server package is not a user account, and its permissions should be limited to the APIs it needs.
Monitoring and hygiene
Audit logs and user activity reports help investigate changes. Inactive users, unused API packages, and over-broad roles are common findings. Data retention and send history settings affect what you can review later. Traps: assuming an API integration inherits a user's permissions; assuming deleting a user deletes their send history; assuming SSO users do not need roles.
Worked example: a contractor needs to view email assets in one Business Unit only. Create a role with view-only Email and Content Builder permissions, assign it in that BU, and do not give Administrator. Rule of thumb: if the request names one task, grant one permission set, not an entire admin role.