Access De-provisioning Policy

1. Purpose

This policy describes how Vizno provisions, modifies, and revokes access to production systems and third-party vendor consoles for personnel as roles change or engagements end. The intent is to ensure that no individual retains access to systems that store or process consumer data after the business basis for that access has ended.

2. Scope

This policy applies to all personnel with any form of access to Vizno production systems or third-party vendor consoles, including:

• Founder and full-time staff.
• Contractors and contributing engineers.
• Any vendor support representative who is granted temporary access for a specific support engagement.

3. Systems under access management

The following systems are tracked in the access inventory and are subject to provisioning and de-provisioning workflow:

Category	Systems
Source control	GitHub (vizno repository, organization membership)
Infrastructure	Coolify (Hetzner orchestration), Hetzner Robot, Tailscale tailnet
Database	PostgreSQL (via Tailscale + application credentials)
Application	Vizno admin role (profiles.role = 'admin')
Object storage	Cloudflare R2 (via Cloudflare account)
DNS / edge	Cloudflare account
Email	Resend account
Payments	Plaid, Increase, Payoneer dashboards
AI	Anthropic console
Other	Any vendor console where Vizno data is reachable

4. Provisioning

Access is granted on a need-to-know basis. To grant access:

1. The founder authorizes the access in writing (a recorded message, ticket, or email exchange acceptable).
2. The minimum role required for the work is selected; broad-scope roles (Owner, Admin, full repository write) are avoided where a narrower scope is sufficient.
3. The individual's account is enabled with multi-factor authentication required before the first sign-in.
4. The grant is recorded in the access inventory (date, system, role, justification).

5. Modification

When a person's role changes (e.g., a contractor transitions from one project area to another, or a contributor steps back from production work):

1. The founder reviews the existing access list against the new scope of responsibility.
2. Access not required for the new scope is revoked within 7 calendar days of the role change.
3. The modification is recorded in the access inventory.

6. De-provisioning (termination or end of engagement)

When a person's engagement with Vizno ends:

1. Within 24 hours of the end of the engagement, the founder revokes access to:
   • The application admin role (the row in profiles.role is downgraded; any active sessions are invalidated server-side).
   • The Vizno GitHub repository and organization membership.
   • The Tailscale tailnet (the device key is removed).
   • The Coolify and Hetzner Robot consoles.
2. Within 7 calendar days, the founder revokes access to:
   • All third-party vendor consoles in the access inventory (Cloudflare, Resend, Plaid, Increase, Payoneer, Anthropic, etc.) where the individual had a named account.
   • Any service-account credentials the individual was the named owner of are rotated.
3. Within 14 calendar days, the founder confirms:
   • Removal from any shared password manager vault or shared note containing credentials.
   • That any artifacts the individual produced (commits, configuration changes) are owned by an active team member or by the company.
4. The de-provisioning is recorded in the access inventory with a date and a checklist confirming each system was processed.

7. Periodic access review

The full access inventory is reviewed quarterly by the founder. For each entry the reviewer confirms:

• The individual is still actively engaged with Vizno.
• The level of access remains justified by current responsibilities.
• Multi-factor authentication is active on the individual's account in each system.

Access that fails any check is revoked or reduced in the same review cycle.

8. Emergency revocation

In the event of a security incident, suspected credential compromise, or suspected insider risk, the founder may revoke access immediately without following the staged timeline above. Emergency revocations are recorded after the fact with the same level of detail as a scheduled de-provisioning.

9. Records

The access inventory and the record of provisioning, modification, and de-provisioning actions are retained for 3 years from the date of the action.

10. Policy review

This policy is reviewed at least annually by the founder and updated as the team composition, the set of systems in scope, or the company's regulatory posture evolves.

11. Contact

Questions about this policy or access requests: security@vizno.com.