High-impact

Reduce access

Give each person access only to the systems and projects their current work requires, review it when their role changes, and remove it the day they leave.

Why this matters

Access is easy to grant and easy to forget. People are added to a project, moved onto the next one, and never removed from the last — so over a couple of years the number of people who can reach any given title quietly grows, long after anyone needed to.

That matters because it decides how bad an incident is rather than whether one happens. One compromised account should expose one project, not the whole library. Keeping access tight is what limits the damage when a password is stolen or a laptop goes missing.

If you work alone, the same principle applies to your own accounts and the tools you connect to them: keep the access you need for the work in front of you, and revoke the rest.

Reduce access — checklist

  • List where unreleased content actually lives: storage, review platforms, transfer tools, edit systems and any client portal.
  • For each one, export the current list of who has access. The list is usually longer than anyone expects.
  • Remove anyone who has left, finished their project, or changed role. Start with former freelancers, who are the most common leftovers.
  • Set access per project rather than per person where the system allows it, so people see the title they are working on and nothing else.
  • Separate viewing from downloading. Plenty of people need to watch a cut; far fewer need a copy of the file.
  • Reserve administrator rights for the small number of people who administer systems, and give everyone else an ordinary account.
  • Turn off or expire old share links. A link that still works a year later is access you did not know you had granted.
  • Add access removal to the leaving process so it happens on someone's last day, not whenever it is noticed.
  • Review the lists quarterly, and again at the end of each large project.