A forgotten service account can sit in your systems for years, retaining authentication privileges that let it keep moving data, calling APIs, or giving a vendor quiet access long after the original project ended.
That is a real risk for justice nonprofits, because your systems often hold sensitive client, case, and partner data. A simple service account register, fundamental to identity and access management in your nonprofit’s security strategy, gives you a faster way to see what exists, who owns it, and what should be shut down first.
Key takeaways
- Build your managed service account register in 30 days, not six months.
- Give every non-human account one named business owner and one technical contact.
- Track purpose, system access, credential type, last review date, and shutdown triggers.
- Review the register on a set rhythm, or it will drift back into guesswork.
Why a service account register matters in justice work
A service account is a non-human account used by an app, script, integration, backup tool, or vendor process. These accounts often have broad permissions and IAM roles. Meanwhile, nobody remembers who approved them.
That gap creates risk fast. An old intake form may still push data into a case system. A former vendor may still have an automation account. A backup job may run with more access than it needs. If you work with confidential legal or client information, that is more than sloppy housekeeping.
You have likely seen the broader pattern already: vendor access sprawl and data risks grow when ownership is weak. The same logic applies to service accounts. If no leader owns the account, no one can approve its access, review its use, or retire it on time.
Google Cloud’s service account security guidance makes the same point in technical terms. Even if you do not use Google Cloud, the rule still holds in Active Directory and Windows Server environments. Service accounts need tight scope, clear owners, and regular review.
If a service account can touch client data, money, or critical systems, you need a named owner.
Days 1-10: Find every non-human account
Start with a plain spreadsheet. You are not building a perfect system yet. You are building visibility.
Look across your case tools, productivity suite, cloud platforms (check via the Google Cloud Console, gcloud CLI, or Cloud Shell), backup systems, finance apps, identity provider, and vendor-managed tools. Then ask program, operations, finance, and IT where automations live, including integrations using REST API or the Admin SDK API. You will usually find more accounts in scripts, connectors, and old vendor setups than in your formal documentation.
Keep the first version simple. These fields are enough to get moving:
| Register field | Why you need it |
|---|---|
| Account name | You need a unique record |
| System or platform | You need to know where it lives |
| Project ID | You need to pinpoint the specific project |
| Purpose | You need to know why it exists |
| Business owner | You need someone accountable |
| Technical contact | You need someone who can change it |
| Access level | You need to spot overreach |
| Credential type | You need to track keys, secrets, or OAuth |
| Last reviewed | You need a review trail |
| Retirement trigger | You need a clear shutdown point |
If you cannot fill most of those fields, your control is weak.
During these first ten days, resist the urge to debate tools. Your goal is a working inventory. If you need a broader method for mapping workflows and tightening access, use that lens here too. Map what exists first. Clean it up second.
Days 11-20: Assign owners and cut access down
Now you move from inventory to decisions.
Each account should have one business owner. That person approves why the account exists and what it may access. You should also name one technical custodian, usually internal IT or a managed partner, who handles setup and changes. Those roles are different, and that distinction matters.
Next, reduce access. Many service accounts start broad because broad access is easier. Months later, nobody remembers to scale it back. Review each account against current use, not original intent. Shift to RBAC principles or assign accounts to a specific user access group for tighter control. If an automation only reads referral data, it should not have write access to the full case system. If a vendor only needs file transfer, it should not keep admin rights.
Keys deserve extra care. Old keys often outlive staff, projects, and vendor contracts, especially unmanaged private keys or misplaced json key files tied to client ID and client secret credentials. Guidance on managing service account keys is clear on this point. Rotate them, limit them, and remove them when you can replace them with safer methods.
Watch for three red flags during this phase:
- Accounts with no clear owner
- Accounts tied to former vendors or former staff
- Accounts with admin rights and no recent review
These are the accounts that turn a routine audit into a leadership problem.
Days 21-30: Approve the register and make it stick
By now, your register should show the real picture. Some accounts are valid. Some need tighter access. A few should be shut down right away.
Use the last ten days to formalize three habits that form the foundation of a broader credential management strategy. First, approve the register with leadership. Second, tie it to vendor onboarding and offboarding. Third, set a review rhythm, usually monthly for high-risk accounts and quarterly for the full list.
You also want triggers. New integration? Add it to the register before launch. Vendor exit? Review and remove accounts before the final invoice. New grant program handling sensitive data? Review account access before service starts. Account granted domain-wide delegation? Update the register immediately. Changes to the OAuth consent screen? Review and approve access right away.
If you want proof that tighter ownership improves calmer execution, these cyber readiness and access control results show what that discipline looks like in practice.
Service account register FAQs
Is this only an IT task?
No. IT can maintain the file, but leadership should require named business owners. While a business owner is named, the organization administrator provides technical oversight. Otherwise, the register becomes a technical list with no accountability.
How often should you review it?
Review high-risk accounts monthly. Review the full register at least quarterly. Also review it when vendors change, staff leave, or a major workflow changes.
What about service accounts in Windows environments?
In Windows environments, include group managed service accounts and those using a service principal name in the register.
What about vendor-created service accounts?
Keep them in the same register. If a vendor created it, you still need to know the purpose, access level, owner, and retirement trigger.
A 30-day service account register will not solve every access problem. It will, however, replace fog with a usable map.
That is often the turning point. Once you can see every non-human account, manage its security context and application default credentials used by developers, and name who owns it, you can make better decisions with less stress.