Personnel Onboarding and Offboarding Policy

Organization: Strategic Habits Consulting, LLC, doing business as Gevell and TheAccessible.Org Owner: Larry Anglin, CTO Effective date: 2026-09-23 Parent policy: Information Security Policy

1. Scope

This policy covers every person who is given access to Company systems. That includes members, employees, contractors and temporary helpers.

Today the Company has two members and no one else:

• Larry Anglin (CTO) has production infrastructure access.
• Laura Hopkins (Chief Accessibility Officer) has no production infrastructure access.

This policy sets the rules for any change to that list, and for reviewing it.

2. Principles

• Least privilege. Access is granted for a role, not by default. Access to production infrastructure (AWS, Cloudflare, Supabase) is limited to the CTO. Giving it to anyone else needs a written reason and the CTO’s approval.
• Named accounts only. Every account belongs to one person. Shared logins are not allowed.
• MFA everywhere. Each account must have multi-factor authentication turned on before it is used.
• Central identity where available. Accounts are created through the central identity systems listed in §3, so they can be removed in one place.

3. Systems covered and how access is provisioned

System	How access is granted	Who has it today
Google Workspace (email, documents)	Workspace user account created by the CTO	Both members
GitHub (source code)	Membership in the Company GitHub organization or repository, with the lowest role that works	CTO (admin). Other access to be confirmed; see actions.
AWS	User in AWS IAM Identity Center, assigned a permission set. No IAM users or access keys for people.	CTO only
Cloudflare (Zero Trust / Access, DNS, Pages, R2)	Cloudflare account member with a scoped role. Internal apps are reached through Access policies.	CTO for the account. Access-policy membership to be confirmed; see actions.
Supabase	Supabase organization member	CTO only
Stripe	Stripe team member with a scoped role (for example, Support or View-only)	To be confirmed; see actions
Gevell application admin role	Admin flag on the user’s profile in the application	To be confirmed; see actions

4. Onboarding

Before anyone is given access:

1. Access request. The CTO records who the person is, their role, which systems from §3 they need, and at what level. The record is a GitHub issue labeled access.
2. Security acknowledgement. The person reads and signs an acknowledgement of the Information Security Policy, including its acceptable-use section, and of this policy. For contractors, this is added to the contract. The contract also includes confidentiality terms and, if they will handle student records, FERPA confidentiality terms.
3. Background check. Anyone who will have access to customer data or production systems must have a background check before access is granted, as far as local law allows.
4. Provisioning. The CTO creates each account, confirms MFA is on, and records the account in the access register (§7).
5. Device. The person’s device must meet the laptop requirements in the Information Security Policy: full-disk encryption, screen lock and automatic updates. The CTO confirms this before access is granted.

Contractor access has an end date. It is removed on that date unless it is renewed in writing.

5. Role changes

When someone’s duties change, the CTO:

• adjusts their access within 5 business days;
• removes access that the new role does not need;
• updates the access register.

6. Offboarding

All access is removed on the person’s last working day. If they leave for cause, or access is removed involuntarily, it is removed immediately. The CTO works through this checklist and keeps the completed checklist on the offboarding issue.

• Google Workspace: suspend the user, sign them out of all sessions, and move ownership of their files and mail to the CTO.
• GitHub: remove them from the organization and repositories, and revoke any personal access tokens or deploy keys they created.
• AWS IAM Identity Center: disable the user and remove their permission-set assignments.
• Cloudflare: remove them from the account, remove them from Access policies, and revoke their active Access sessions.
• Supabase: remove them from the organization.
• Stripe: remove them from the team.
• Gevell app: remove the admin role from their user profile.
• Other accounts in the access register (for example Twilio, Resend, Telegram alert channels, domain registrar or password manager): remove them.
• Rotate secrets the person could have seen. This means any credential in a system they could reach, or any credential shared with them. Follow the secrets inventory and rotation runbook, and log each rotation there.
• Devices: staff laptops are personally owned. The person removes all Company accounts, sessions, passkeys, SSH keys and Company files (source checkouts, .env files) and confirms in writing. The CTO revokes the device’s sessions and passkeys from the Company side. Personal devices are not wiped or collected (Information Security Policy §7, Media Handling Policy §4). Any Company-owned device is returned and wiped under the Media Handling Policy.
• Access register: update it, and confirm no accounts remain.

If the CTO leaves or is unavailable. Because only the CTO has production access, continuity of access is covered by the Business Continuity Plan.

7. Access register and quarterly access review

• The CTO keeps an access register. It lists, for each person, every system they can reach, their role in that system, and whether MFA is on.
• Every quarter, the CTO:
  • checks the register against the live member lists in each system in §3;
  • removes accounts that are no longer needed;
  • checks that MFA is still on for each account;
  • looks for any leftover API tokens or keys.
• The review is recorded with the date, what was found and what was changed.

Actions required to make this policy true

1. Create the access register. Record every system and account for both members. Resolve the “to be confirmed” cells in §3, especially:
   • Laura’s GitHub, Stripe and Cloudflare Access memberships;
   • whether Laura has the Gevell app admin role at admin.gevell.com. The employee triage tool at admin.gevell.com/admin/triage suggests she uses the admin site. If the admin role can show customer data, say so accurately in questionnaires.
2. Get signed security acknowledgements from both members. None exist today.
3. Run the first quarterly access review and record it in docs/admin/security/access-reviews/. Consider adding an access-review checklist to the existing quarterly .github/workflows/rotation-reminder.yml issue so reviews are prompted automatically.
4. Create the access GitHub issue label. Also create an offboarding issue template that contains the §6 checklist.
5. Bring the secrets inventory up to date. secrets-inventory-and-rotation.md is dated 2026-04-20 and still lists static AWS keys held in GitHub Actions. Those were removed in the 2026-09-05 OIDC migration. Its rotation log (§5) has never been filled in. The departure rotation step depends on this document being accurate.
6. Confirm that Google Workspace is the identity for the other systems where that makes sense (SSO into GitHub, Cloudflare Access and similar). Otherwise, reword “central identity” in §2 so it is accurate. Today, AWS uses IAM Identity Center, and the other systems use their own accounts.
7. Background checks: decided. The §4 requirement for future hires was kept when this policy was approved on 2026-09-23.