The existance of "the" key is not an inherent problem in situations like this. Instead, it speaks to poor key management practices by the people responsible for implementing cryptography for an organization.
Consider, as an analogy, the (poor) practice of using shared passwords. What do you do when you fire someone who had legitimate access to this password? You have to change everything or risk a compromise of all the systems sharing this password. Hence, the need for tools like sudo that separate authentication (what password / auth key) and access control (what rights).
With encryption, it's similarly possible to break one big risk domain into lots of smaller ones using things like separate trust anchors (for authentication) or encryption keys (for access control). For example, If your org gets served a subpeona for your financial records you can give them your tape backups for the relevant time periods plus the necessary decryption key, but withold the decryption key for the backups of your R&D data and the signing key for your VPN.
Consider, as an analogy, the (poor) practice of using shared passwords. What do you do when you fire someone who had legitimate access to this password? You have to change everything or risk a compromise of all the systems sharing this password. Hence, the need for tools like sudo that separate authentication (what password / auth key) and access control (what rights).
With encryption, it's similarly possible to break one big risk domain into lots of smaller ones using things like separate trust anchors (for authentication) or encryption keys (for access control). For example, If your org gets served a subpeona for your financial records you can give them your tape backups for the relevant time periods plus the necessary decryption key, but withold the decryption key for the backups of your R&D data and the signing key for your VPN.