The Question at Hand
When the Department of Homeland Security's Inspector General found that all 76,000 CBP network users could operate service accounts with elevated privileges, the agency blamed human error. This raises a question every security team faces: should you rely on manual processes to manage privileged access, or should you deploy automated privileged access management (PAM) tools?
This isn't just about technology. It's about how you allocate resources, where you accept operational friction, and what failure modes you're willing to live with. Both approaches have advocates and come with real tradeoffs.
The Case for Manual Access Management
Some security teams keep privileged access management manual for solid reasons.
First, manual processes force human review at every decision point. When someone submits a ticket for admin access, a security engineer reviews the business justification, checks the user's role, and makes a judgment call. This friction prevents casual overprovisioning and creates checkpoints where people ask, "Does this person actually need root access, or just read access to these directories?"
Second, manual processes are transparent and auditable. You have a ticket trail, approval chains, and human-readable logs. When an auditor asks, "How do you ensure segregation of duties for database admin accounts?", you can show your ticketing system, detailing who requested access, who approved it, and the business justification.
Third, manual processes don't require capital investment in PAM platforms. For smaller organizations pursuing their first SOC 2 Type II or ISO/IEC 27001 certification, this matters. A PAM solution can be costly. If you're a 200-person company with 15 privileged accounts, building controls around a ticketing system and documented procedures might be the right decision.
Finally, manual processes require you to document your access control logic explicitly. You can't hide behind vendor defaults. Every access decision is documented, ensuring your team understands the access model they're operating.
The Case for Automated PAM
The counterargument is that manual processes don't scale and fail predictably.
The CBP audit mapped more than 100 attack paths through the environment. That's a visibility problem. When you manage privileged accounts manually, you lose track of what exists. You don't know which service accounts have domain admin rights or which former contractors still have VPN access.
Automated PAM tools solve the inventory problem. They discover privileged accounts, vault credentials, rotate passwords, and log every session. When an auditor asks, "How many accounts can modify your SIEM configuration?", you have an answer in real time.
Human error is everyone's problem. People forget to revoke access when someone transfers internally. They grant temporary elevated access and forget to remove it. ISO/IEC 27001 Clause 5.18 and SOC 2 CC6.2 require periodic access reviews, but manual reviews are snapshots. Automated PAM provides continuous monitoring.
The real argument for automation is operational risk. When you can't inventory privileged accounts, you can't monitor them. When you can't monitor them, you can't detect compromise. The Inspector General's report noted that CBP couldn't always tell which accounts had elevated privileges. That's an architecture issue. Manual processes can't maintain accurate state across a complex environment.
Where Practitioners Actually Land
Most organizations use a hybrid approach, automating high-risk, high-volume scenarios and keeping manual controls where human judgment adds value.
Common patterns:
- Automate service account management and password rotation, but keep manual approval workflows for human privileged access.
- Deploy PAM for production systems and sensitive data environments, but use manual processes for lower-risk development infrastructure.
- Automate discovery and inventory, but require manual review before revoking access to avoid operational disruption.
- Use PAM for session recording and audit logging, but keep manual ticketing for access requests to preserve the approval trail.
The hybrid approach acknowledges that different control objectives need different implementations. ISO/IEC 27001 Annex A.9.2.1 doesn't mandate automation. It requires a formal process that works reliably. You decide what "reliably" means for your risk profile.
Our Take
If you're managing more than 20 privileged accounts across multiple systems, manual processes will fail you. Not because your team is incompetent, but because manual processes can't maintain accurate state as your environment changes. The CBP case isn't an outlier. It's what happens when you scale manual access management beyond its limits.
But automation isn't a substitute for access control design. Before deploying a PAM platform, answer: who should have privileged access, under what circumstances, with what approval requirements, and for how long? Those are policy questions. Tools execute policy, they don't create it.
The right sequence: document your access control requirements, implement them manually to prove the process works, then automate the parts that require continuous monitoring or frequent repetition. If you automate first, you'll encode bad access decisions into your tooling and make them harder to fix later.
For SOC 2 Type II, automated PAM supports CC6.2, CC6.3, and CC7.2. For ISO/IEC 27001, it addresses Annex A.9.2.1, A.9.2.3, and A.9.4.3. But the controls exist whether you automate them or not. Automation is how you make them sustainable at scale.
Human error will always be part of the equation. The question is whether you build systems that make errors detectable and correctable, or whether you rely on perfect execution from imperfect humans. CBP chose the latter. You don't have to.
