Access Control & Password Policy

• Applies to staff, contractors, and service accounts.
• Covers laptops, cloud services, code repos, and hosted systems we manage.
• Client-owned platforms follow client rules; we add these as a minimum.

• Least privilege and need-to-know.
• MFA first, everywhere it is available.
• Unique identities; no shared human accounts.
• Time-bound access with regular review.

• Provisioning: access is granted via ticket or written request approved by a project lead or director.
• Joiner/Mover/Leaver: create on start; adjust on role change; remove same day on exit.
• Reviews: access recertification at least every 90 days for client and admin systems.
• Third parties: use guest accounts with limited roles; review every 30 days.
• Break-glass: one emergency admin per platform, stored in a vault, use logged and rotated after use.

• MFA: required for email, cloud admin, code repos, payment or data stores, and any client admin.
• SSO: prefer SSO where available; otherwise enforce MFA per account.
• API keys and tokens: store in an encrypted vault or platform secrets; never in code or chat.

• Use a password manager for all credentials.
• Minimum 12 characters; passphrases preferred; avoid reuse.
• No sharing of passwords. Use group roles or delegated access instead.
• Rotate shared technical secrets (not human passwords) when people leave or roles change.
• Change default credentials before first use.

• SSH: use key pairs, not passwords. Protect private keys with a passphrase.
• Service accounts use scoped API tokens with the smallest needed permissions.
• Rotate keys on compromise, role change, or every 90 days for high-risk systems.

• Define reader, contributor, and admin roles per system.
• Admin access is temporary and logged; use elevation just-in-time where supported.
• Disable dormant accounts after 30 days of inactivity; delete after 60 unless needed.

• Store secrets in a vault or platform secrets store; never commit to repos.
• Mask secrets in logs and screenshots.
• Rotate immediately after suspected exposure and update all references.

• Log admin actions, failed logins, and privilege changes.
• Alert on excessive failures, new admins, and API token creation.
• Keep access logs for 30–90 days unless a client requires longer.

• Use client SSO where offered; otherwise use client-issued accounts with MFA.
• Keep a list of who has access and why in the project folder.
• Remove our access within 5 working days after project end, then confirm in writing.

• Report suspected compromise immediately to the Security Lead.
• Revoke tokens, reset passwords, and review logs.
• If personal data may be affected, follow the Incident Response Policy and DPA notice steps.

• Breaches may lead to access removal and contract action.
• Policy review at least yearly or after major changes in platforms.

Questions about this policy?

Technophobia Ltd · Company No. 14898332 · VAT GB 495 7043 58
13B Devonshire Road Industrial Estate, Millom, LA18 4JS, United Kingdom
+44 1229 774591 • hello@technophobia.uk