The Access Control Policy governs how botBrains creates identities, authenticates users, and grants the minimum access each person needs to do their job. It’s the canonical home for our rules on authentication, multi-factor authentication, least privilege, role-based access, the joiner-mover-leaver lifecycle, and passwords. Other policies link here rather than restate these rules.
botBrains is not yet ISO 27001 certified. We are preparing our ISMS and writing these policies as part of pursuing certification, and we fully intend to get our controls attested.
Scope
This policy applies to every system that botBrains uses to process, store, or transmit business or customer data, including our cloud providers (AWS, Hetzner, DigitalOcean), source control (GitHub), email, observability tooling (Better Stack, Sentry, Langfuse), the password manager, and the botBrains platform itself. It covers both team members and any external party granted access.
Principles
botBrains grants access on the principle of least privilege: a person receives only the access required for their current role, and the platform denies anything not explicitly granted by default. We use role-based access control (RBAC) wherever a system supports it, assigning roles rather than ad-hoc individual permissions. Because botBrains is a two-person company, the CISO owns access decisions and the person making the grant records the approval. We accept that one individual may both request and approve access and treat the resulting segregation-of-duties limitation as a documented, accepted risk (see Risk Management Policy).
Identity and authentication
| Control | Rule |
|---|
| Unique accounts | Every person has their own named account. Accounts are never shared between people. |
| Multi-factor authentication | botBrains enforces MFA on all critical systems, including cloud consoles, GitHub, and email. Where a system offers MFA, users must turn it on. |
| Password manager | The shared password manager generates and stores credentials. Personnel never write down, email, or store passwords in plaintext. Local development secrets are the exception: developers keep them in untracked .env files on their encrypted laptop, never committed to source control or shared. |
| Privileged access | botBrains limits administrative and root access to production to the minimum personnel, with MFA. MFA protects provider root accounts, which we use only when necessary. |
| Remote access | botBrains encrypts connections to production systems and networks and protects them with MFA. Access to production servers requires the company VPN. See Cryptography Policy. |
| Session protection | Laptops lock automatically when idle and use full-disk encryption (FileVault or BitLocker). |
Password requirements
End-user and customer authentication on the botBrains platform is managed by Clerk, our authentication provider, which enforces the controls below. botBrains team accounts apply the same baseline through their identity providers where configurable.
| Requirement | Setting |
|---|
| Minimum length | At least 8 characters |
| Complexity | At least three of upper case, lower case, number, and special character |
| Trivial passwords | Clerk rejects common and guessed passwords |
| Reuse | Password history of 5 prevents reuse of recent passwords |
| Lockout | Accounts lock after repeated failed attempts |
| Storage | Clerk salts, peppers, and stores passwords as one-way hashes, and never displays or transmits them in plaintext |
Joiner, mover, leaver
Access changes follow a person’s relationship with botBrains, and the CISO records them.
| Event | Action |
|---|
| Joiner | The CISO verifies the new user’s identity and records the verification method before provisioning. botBrains provisions access only after onboarding obligations, including confidentiality terms, are in place, and limits it to what the role requires. No one receives access before the start date. |
| Mover | On a role change, botBrains adjusts access to match the new role and removes any access no longer needed. |
| Leaver | botBrains revokes all access on the last working day, target same business day. We retire accounts rather than reuse them, and rotate shared credentials the person knew. |
Access reviews
The CISO reviews accounts and their privileges across all in-scope systems at least annually, and on every role change, to confirm access still matches need. The CISO records each review in Notion (Employees Only: Access Reviews) so an auditor can see them.
Application access
The botBrains platform is multi-tenant with logical separation by tenant ID and RBAC-based authorization, so customers reach only their own data. Application users never have direct database access. botBrains removes default and vendor accounts or changes their credentials before using a system.
ISO 27001 mapping
This policy supports Annex A 5.15 (access control), 5.16 (identity management), 5.17 (authentication information), 5.18 (access rights), 8.2 (privileged access rights), 8.3 (information access restriction), and 8.5 (secure authentication).
Enforcement and exceptions
Violations may lead to suspension of access and disciplinary action. The CISO must approve and record any exception with the reason and an expiry date.
Review
The CISO owns this policy and reviews it at least annually and on any material change. 
