Loading module...
Loading module...
GSA-05
Learn why you should only hold the access you need, how permission creep creates risk, and what happens when offboarding access removal fails.
General Security Awareness Training
Estimated Time: 15 minutes
By the end of this module, you will be able to:
In Module 1, we walked through the attacker's playbook. Step 3 was lateral movement: once an attacker gets into one account, they explore, looking for paths to higher-value systems and data. The amount of damage they can do at this stage depends entirely on how much access the compromised account has.
If a marketing coordinator's account has access only to the marketing team's shared drive and the company blog CMS, an attacker who compromises that account can reach those two systems and nothing else. But if that same account also has lingering access to the customer database (from a one-time project six months ago), the engineering wiki (from a cross-functional initiative that ended last quarter), and an admin panel (because someone checked a box during onboarding that was never unchecked), the attacker just inherited a much larger playground.
This is the core problem that access control solves. Every permission you hold is a permission an attacker inherits if your account is compromised. Fewer permissions mean a smaller blast radius. That's not just a security team concern. It directly affects you, because the amount of damage that can be done through your account determines the severity of an incident that starts with your credentials.
The principle of least privilege is straightforward: every user should have the minimum level of access necessary to do their job, and nothing more.
This applies in three dimensions:
Scope: You should have access only to the systems, data, and tools your role requires. An account manager needs access to the CRM. They probably don't need access to the production database or the CI/CD pipeline.
Level: Even within a system you legitimately need, your permission level should match your actual work. If you only need to read reports in a tool, you shouldn't have write or admin access. If you need to edit documents in a shared drive, you don't need the ability to change sharing permissions for the entire folder.
Duration: Access that's needed for a specific project or task should expire when that project or task ends. Temporary needs shouldn't become permanent permissions.
SOC 2 auditors look for evidence that your company applies least privilege consistently. Common Criteria 6.1 (CC 6.1) requires that logical access to systems and data is restricted to authorized users. Auditors will review access lists, check whether permissions align with job roles, and look for evidence of regular access reviews. If they find accounts with permissions that can't be justified by the person's current role, that's a finding.
Permission creep (sometimes called privilege creep or access creep) is the gradual accumulation of access rights beyond what a person actually needs. It's one of the most common security problems in growing companies, and it almost never happens because someone made a bad decision. It happens because of completely reasonable decisions that nobody revisited.
Here's how it typically plays out:
Onboarding generosity. A new employee starts, and IT provisions their accounts. To avoid blocking the new hire from anything they might need, the provisioner errs on the side of more access rather than less. The new employee never uses half of those permissions, but they're never removed either.
Role changes without access cleanup. An employee moves from engineering to product management. They get new access for their product role, but nobody revokes their engineering access. Six months later, they still have commit access to the codebase, access to production infrastructure, and membership in engineering-only Slack channels. They're effectively carrying two roles' worth of permissions.
Project-based access that never expires. A sales operations analyst gets temporary access to the billing system to help with a quarter-end reconciliation project. The project ends. The access stays. Three quarters later, the analyst still has access to every customer's billing record, and nobody remembers why.
"Just in case" access. A manager requests admin access to a tool because they need it "once in a while." The access is granted. That "once in a while" was actually once, eight months ago. The admin access persists indefinitely.
Studies consistently show that the vast majority of SaaS users, some estimates say 85% or more, have more permissions than their roles require. In a SOC 2 audit, this kind of sprawl creates findings. In a security incident, it creates blast radius.
Shared accounts (a single username and password used by multiple people) are one of the most persistent access control problems in small and mid-size companies. They're common because they feel convenient: a shared support@company.com inbox, a team login for a third-party tool that charges per seat, or a shared admin account for a system that "only a few people ever need."
The problem is accountability. When multiple people share a single set of credentials, you lose the ability to answer the most basic security question: who did what?
If the shared account is used to delete data, approve a transaction, or access a restricted system, your audit trail shows only that "the account" took the action. It can't tell you which human being was behind it. This creates three specific problems:
Incident investigation becomes impossible. If a shared account is compromised or misused, you can't determine who was responsible or when the compromise occurred. Every person who has the credentials is a suspect, and the timeline is unrecoverable.
SOC 2 auditors will flag it. CC 6.1 requires individual accountability for access. Shared accounts directly undermine this requirement. Auditors expect to see that every action in a system can be attributed to a specific person.
Password management breaks down. When someone who uses the shared account leaves the company, the password should be changed immediately. In practice, this rarely happens. The more people who share a credential, the harder it is to rotate, and the longer a former employee retains access without anyone realizing it.
If your team uses shared accounts today, flag it to your manager or IT team. The fix is usually straightforward: individual accounts with role-based access, even if it means adjusting a SaaS subscription tier.
Of all the access control risks covered in this module, offboarding failures may be the most dangerous because they create vulnerabilities that persist silently for weeks or months.
When an employee leaves the company, their access to every system, tool, and data store should be revoked on or before their last day. In practice, this is harder than it sounds. The average SaaS company uses dozens (sometimes hundreds) of tools, and a departing employee may have accounts, OAuth tokens, API keys, and shared folder access scattered across all of them. Research shows that 50% of companies have discovered former employees still accessing SaaS applications months after departure.
Here's what incomplete offboarding looks like in practice:
The primary accounts get disabled, but the secondary ones don't. IT disables the employee's email and SSO login, but the employee also had direct accounts on tools that bypass SSO: a personal Trello board connected to company data, a Figma account, a HubSpot login, a Notion workspace. Those accounts remain active.
OAuth tokens survive account deactivation. The employee authorized a third-party app to access company data via OAuth. Even after their primary account is disabled, the OAuth token may remain valid, allowing continued data access through the connected app.
Shared credentials aren't rotated. The employee knew the password to a shared team account, a shared Wi-Fi network, or a shared API key. Nobody changes those credentials after the departure.
The contractor's engagement ends quietly. A freelancer's three-month project wraps up. Nobody sends a formal offboarding request to IT because there was no formal onboarding in the first place. The contractor's access persists indefinitely.
Every one of these scenarios creates a window for unauthorized access, whether by the former employee, by an attacker who later compromises those dormant credentials, or by anyone who stumbles across them. And because the access is legitimate from the system's perspective (valid credentials, valid tokens), security monitoring tools may not flag it.
Access reviews (also called user access reviews, or UARs) are the mechanism for catching permission creep, shared accounts, and offboarding gaps before they become audit findings or security incidents.
In a typical access review, managers or system owners are asked to verify that each person's access to their systems is still appropriate for their current role. If it's not, the access is revoked or adjusted.
SOC 2 auditors expect access reviews to happen at least quarterly for sensitive systems. Many organizations run them more frequently for systems that handle Restricted or Confidential data.
What this means for you: Periodically, your manager or IT team will ask you to confirm that the access you have is still necessary. Take this seriously. It's not bureaucratic busywork. It's a control that prevents your account from becoming a larger liability than it needs to be. If you notice that you have access to systems you no longer use or roles you no longer need, proactively request that the access be removed. You're not losing something valuable. You're reducing the damage that could be done through your account if it's ever compromised.
Access control is primarily an IT and security team responsibility at the infrastructure level. But every employee plays a role in keeping permissions tight and accountable:
Don't request more access than you need. When you need access to a new system or tool, request the minimum level that lets you do the job. If you only need read access, don't request write access "just in case."
Speak up when you no longer need something. If a project ends and you still have access to systems that were provisioned for it, let IT know. This is especially important for access to production systems, customer data, or financial tools.
Don't share your credentials. Ever. Not with a colleague covering for you, not with a contractor who "just needs to check one thing," not with your manager. If someone else needs access, they should request their own account.
Flag shared accounts when you encounter them. If your team uses a shared login for any tool, raise it with your manager or IT. There may be a legitimate reason, or it may be an inherited practice that nobody has questioned.
Participate meaningfully in access reviews. When you're asked to review your access or your team's access, actually look at the list. If you see permissions that don't match current job responsibilities (including your own), flag them for removal.
Report offboarding gaps. If a colleague leaves and you notice they still have access to a shared drive, a Slack channel, or a tool, let IT know. You may be the only person who notices.
Next up: Module 6, Safe Browsing & Secure Work Habits, where we'll cover malicious links, QR code attacks, public Wi-Fi risks, device security, and the shadow IT problem.
Module Version: 1.0
Last Updated: March 2026
Framework References: NIST Cybersecurity Framework 2.0 (Protect, Govern), SOC 2 Trust Services Criteria (CC 6.1, CC 6.2, CC 6.3)
Data Sources: Verizon Data Breach Investigations Report 2025, Ponemon Institute 2025 Cost of Insider Risks Report