Access Management
We operate on the principle of least privilege: every team member has exactly the access they need for their role, nothing more.
The Squad Model
Each client engagement is served by a squad, a small team assigned to your project.
How Squads Work
- Dedicated credentials: Each squad member receives project-specific access credentials
- Squad Staffing: We provide you with the names, emails, title and dates of access for every squad member
- Access Boundaries: We keep track of access so we can revoke it immediately if someone leaves the project
Squad Composition
A typical squad includes:
| Role | Responsibility | Access Level |
|---|---|---|
| Project Manager | Coordination, client communication | Project management tools, documentation |
| Engineering Manager | Technical oversight, architecture | Full technical access |
| Engineers | Development, implementation | Code repos, development environments |
| Data Analysts | Data work, reporting | Data systems, analytics tools |
Access is scoped by role: an analyst doesn’t need production deployment access, and a PM doesn’t need database credentials.
Project Isolation
Isolation is enforced technically, not just by policy.
What’s Isolated
- Credentials: Separate accounts per project; no shared logins, all managed through 1Password
- Code repositories: Project-specific repos with no access to other clients’ code. Ideally lives on your github account
- Communication channels: Dedicated Slack channels locked to squad members
- Cloud infrastructure: Separate resource groups (ideally yours), no cross-project access
- Documentation: Project spaces in Notion / Documentation Site restricted to squad members
- Development environments: Isolated environments per engagement
How Isolation Is Enforced
- Role-based access control (RBAC) in all systems
- Project-scoped permissions in GitHub, Azure, AWS
- Channel restrictions in Slack
- Workspace segmentation in Notion
- Automated access provisioning tied to project assignment
Access Lifecycle
Onboarding
When a team member joins a project:
- Identity verification: Confirmed employment and project assignment
- Access provisioning: Project-specific credentials created
- MFA enrollment: Multi-factor authentication required for all systems
- Training confirmation: Security awareness training verified current
- NDA execution: Confidentiality agreement signed
During Engagement
- Regular access reviews: Periodic confirmation that access levels remain appropriate
- Just-in-time access: Elevated permissions granted temporarily when needed
- Activity logging: Actions logged for audit purposes
- Compliance monitoring: MDM and EDR verify device compliance continuously
Offboarding
When a team member leaves a project:
- Credential revocation: All project-specific access disabled immediately
- Session termination: Active sessions ended
- Device wipe: Client data removed from devices (where applicable)
- Access audit: Confirmation that no orphaned access remains
- Documentation: Offboarding recorded for compliance
Offboarding happens immediately after project end or team member departure.
Authentication
SSO Integration
When using your SaaS applications, you issue us emails and we go through your IDP:
- Supported protocols: SAML 2.0 and OAuth 2.0/OIDC
- Identity providers: Entra ID (Azure AD), Okta, Google Workspace, and other standard-compliant IdPs
- MFA enforcement: Multi-factor authentication required for all access
Provisioning Options
- Just-in-Time (JIT) provisioning: User accounts can be created automatically upon first SSO login
- Manual provisioning: We can provision access through defined request workflows
- SCIM-based provisioning: Can be supported if required for automated user lifecycle management
Local Login
Local login can be disabled entirely, ensuring all authentication flows through your SSO provider.
Role-Based Access Control
Permission Levels
| Level | Description | Example Access |
|---|---|---|
| Read | View resources | Documentation, dashboards |
| Write | Modify resources | Code commits, configuration changes |
| Admin | Manage access and settings | User provisioning, system configuration |
| Owner | Full control | Typically client-retained |
System-Specific Implementation
GitHub
- Repository access scoped to project
- Branch protection rules enforced
- Required reviews for merges
- Signed commits where required by client
Azure / AWS
- Resource group isolation
- IAM policies per project
- No cross-account access
- Audit logging enabled
Slack
- Private channels per project
- Restricted to squad members only
- No guest access to project channels
Notion
- Workspace segmentation
- Page-level permissions
- No cross-project visibility
Audit and Monitoring
All access generates logs:
- Authentication events: Login attempts, MFA challenges
- Authorization events: Access grants and denials
- Resource access: What was accessed, by whom, when
- Configuration changes: Who changed what settings
Logs are retained per client requirements and available for review.
Client Controls
Depending on the engagement model, clients may retain additional controls:
- Approval workflows: Client approves access grants
- Direct provisioning: Client provisions access directly in their systems
- Real-time monitoring: Client visibility into access events
- Revocation authority: Client can revoke access at any time
Last updated on