Access Control Policy

Digital Benefits Pte Ltd (trading as WiBiz) Document ID: WBZ-SEC-001 Document Version: v1.0 Effective Date: 15 April 2026 Next Review Date: 15 April 2027 Classification: Internal Parent Policy: WiBiz Information Security Policy v1.0 Owner: Nicklaus D'Cruz, CEO

1. Purpose

This policy defines the requirements for controlling access to WiBiz systems, data, and infrastructure. It ensures that access is granted based on business need, follows the principle of least privilege, and is reviewed regularly.

2. Scope

This policy applies to all access to:

• Platform infrastructure (CRM backend) and all sub-accounts
• Frontend hosting and deployment platforms (Vercel)
• Source code repositories (GitHub)
• Payment processing systems (Stripe, Razorpay)
• Communication channels (WhatsApp Business, Instagram, Facebook, web chat)
• Automation platforms (Make, Zapier)
• Data stores (Airtable, Google Sheets, databases)
• E-signature platform (Adobe Sign)
• Voice services (ElevenLabs)
• Internal tools (Dropbox, Google Workspace, Discord, Notion)
• Client sub-accounts and client data

This applies to all employees, contractors, interns, channel partners, and third-party vendors.

3. Principle of Least Privilege

Every user receives the minimum level of access required to perform their role. No exceptions.

• Access is denied by default and granted only by explicit approval
• Access is never granted "just in case" or for convenience
• Admin-level access is restricted to named individuals with documented justification
• Access to client sub-accounts is limited to team members actively working on that client
• When a team member changes role, access is reviewed and adjusted within 2 business days

4. Role-Based Access Control (RBAC)

WiBiz uses role-based access control across all systems. Roles are defined by job function, not by individual.

4.1 Standard Roles

4.2 Role Assignment

• Roles are assigned by the Security Lead or CEO
• Each user is assigned exactly one primary role
• Temporary elevated access requires written approval from the CEO and an expiry date (maximum 30 days)
• Role assignments are documented in the access register maintained by the Governance lead

5. User Access Provisioning (Onboarding)

When a new team member, contractor, intern, or partner joins:

1. Their manager submits an access request specifying the role and systems required
2. The Security Lead or Governance lead verifies the request against the role matrix (Section 4.1)
3. Accounts are created on required platforms with role-appropriate permissions only — never with a higher role "to be adjusted later"
4. MFA is enrolled on all systems before access is granted (see Section 7)
5. Password set meeting complexity requirements (see Section 6)
6. The user acknowledges this Access Control Policy and the Acceptable Use Policy before access is activated
7. The access grant is logged in the access register with date, approver, and systems
8. Onboarding confirmation sent to the new user

6. Access Changes

• Role changes require a new access request following the same approval process
• Temporary project access is granted with a defined end date and automatically reviewed on expiry
• Access to additional systems requires documented business justification
• Access is adjusted immediately when a team member changes role or team

7. De-Provisioning (Offboarding)

When a team member departs or a contractor engagement ends:

1. All platform accounts disabled within 24 hours of departure confirmation — same day for involuntary departures
2. Active sessions terminated immediately across all platforms
3. API keys and tokens associated with the departing user revoked
4. Shared credentials that the departing user had access to are rotated immediately
5. Access to client sub-accounts removed immediately
6. GitHub and deployment platform access removed
7. Company devices returned or remotely wiped of WiBiz data
8. De-provisioning confirmed and logged by the Governance lead
9. The Security Lead verifies completion within 48 hours

8. Password Requirements

8.1 Password Standards

All passwords for WiBiz systems must meet these requirements:

• Minimum 12 characters
• Must include uppercase, lowercase, numbers, and at least one special character
• No reuse of the last 10 passwords
• No dictionary words or common patterns (e.g. "Password123!")
• Passwords must be unique per system — no credential sharing across platforms
• Must not contain the user's name or email address
• Must not be shared, written down, or stored in plain text
• Password manager use is required (1Password, Bitwarden, or equivalent)
• Passwords must be changed immediately if compromise is suspected

8.2 Password Rotation

• Production system passwords and API keys: rotated every 90 days
• User account passwords: rotated every 180 days
• Shared service account passwords: rotated every 90 days and immediately after any team member departure
• Passwords are rotated immediately if a compromise is suspected

8.3 Password Storage

• Passwords must be stored in an approved password manager only
• No passwords in code repositories, documents, spreadsheets, chat messages, or email
• API keys and secrets must be stored in environment variables or secret management services — never hardcoded in source code

9. Multi-Factor Authentication (MFA)

MFA is mandatory for all production systems. No exceptions.

9.1 MFA-Required Systems

• Platform infrastructure (CRM backend) — admin and operator accounts
• Vercel (frontend deployment)
• GitHub (all repositories)
• Stripe and Razorpay (payment processing)
• Database consoles (Neon Postgres, any direct database connection)
• Google Workspace
• Dropbox
• WhatsApp Business Manager
• Meta Business Suite (Facebook/Instagram)
• Any system containing client data, customer PII, or credentials

9.2 Approved MFA Methods (in order of preference)

1. Hardware security key (FIDO2/WebAuthn)
2. Authenticator app (TOTP — Google Authenticator, Authy, 1Password)
3. SMS-based OTP (accepted only as a fallback where the above are not supported by the platform)

Backup codes must be generated and stored securely in the approved password manager.

10. Session Management

• Inactive sessions must auto-timeout after 30 minutes on all production and administrative systems
• Database consoles: 15-minute inactivity timeout
• Users must manually lock or log out when stepping away from their device
• Screen lock must be configured with a maximum of 5 minutes idle time on all devices

11. Privileged Access Management

11.1 Privileged Accounts

Privileged accounts include: system administrators, production database credential holders, API key holders, billing managers, deployment pipeline owners, and anyone with the ability to modify access controls.

11.2 Privileged Access Controls

• Production database access (Neon Postgres, any direct database connection) is restricted to the CEO and one designated tech lead. No other team member may hold production database credentials.
• Each privileged account is assigned to a named individual — no shared admin accounts
• Privileged actions (deploying to production, modifying environment variables, rotating API keys) require approval from the CEO or tech lead before execution
• Privileged actions are logged and reviewed monthly
• Privileged users must use a separate account for day-to-day non-admin work where the platform supports it
• Unused privileged access is revoked within 7 days of being identified

11.3 Emergency Access

In the event the CEO and tech lead are both unreachable, the Governance lead (Chielo) may authorise emergency access for a maximum of 4 hours, with full documentation of actions taken. Post-incident review is required within 24 hours.

11.4 API Keys and Service Accounts

• API keys are created with the minimum permissions required
• Each integration uses its own API key — no shared keys across services
• API keys have defined owners responsible for rotation and security
• Unused API keys are revoked within 7 days of being identified
• Service account activity is logged and included in quarterly reviews

12. Third-Party Access

12.1 Granting Third-Party Access

Before any third-party vendor or partner receives access to WiBiz systems:

1. A business justification is documented
2. The vendor's security posture is assessed (questionnaire or SOC 2 report where available)
3. Access scope is defined: which systems, what level, for how long
4. A data processing agreement or NDA is signed
5. The CEO or Security Lead approves the access grant
6. Access is provisioned with an expiry date

12.2 Ongoing Third-Party Controls

• Third-party access is reviewed quarterly alongside internal access reviews
• Vendor security posture is reassessed annually
• Access is revoked within 24 hours of contract termination
• Third-party users are subject to the same password and MFA requirements as internal users

13. Remote Access

All WiBiz team members work remotely or in a distributed arrangement. The following controls apply.

13.1 Device Requirements

• All devices used to access WiBiz systems must have: up-to-date OS, active firewall, disk encryption enabled, screen lock configured (maximum 5 minutes idle)
• Personal devices used for work must meet the same requirements
• Lost or stolen devices must be reported within 4 hours

13.2 Network Requirements

• Access to production systems from public Wi-Fi networks requires a VPN or equivalent secure connection (e.g. Cloudflare Access, Tailscale)
• Public Wi-Fi access to production systems is prohibited without an active VPN
• SSH access to servers requires key-based authentication — password-only SSH is prohibited
• Home networks must use WPA2 or WPA3 encryption
• Remote desktop or screen-sharing sessions involving client data must use encrypted connections

13.3 Approved Remote Access Methods

• SSH with key-based authentication (for server access)
• VPN or zero-trust access tool (for production environment access from untrusted networks)
• HTTPS-only web interfaces (for SaaS platform access)
• No unencrypted remote access methods are permitted

14. Access Logging and Monitoring

14.1 What is Logged

• All authentication events (successful and failed login attempts)
• All access provisioning and de-provisioning actions
• All privileged account actions (user creation, permission changes, configuration changes)
• All API key usage
• All access to client sub-accounts

14.2 Log Retention

• Access logs are retained for a minimum of 12 months
• Logs are stored in a tamper-resistant manner (separate from the systems being logged where possible)
• Logs are not accessible to the users whose actions they record

14.3 Monitoring and Alerts

• Failed login attempts: alert after 5 consecutive failures — account locked after 10
• Login from a new device or location: flagged for review
• Privileged action outside business hours: flagged for next-day review
• Access to client sub-accounts outside of assigned client list: immediate alert

15. Access Reviews

15.1 Quarterly Access Review

Every quarter, the Governance lead conducts a full access review:

1. Export the user list from every system in scope (Section 2)
2. Verify each user still requires access and their role is correct
3. Remove access for any user who no longer requires it
4. Flag any access that exceeds the user's role
5. Document findings and actions in the access review log
6. CEO reviews and signs off on the completed review

15.2 Annual Audit

Full audit of all service accounts, API keys, and shared credentials conducted annually.

15.3 Event-Triggered Reviews

Access is reviewed immediately when:

• A team member changes role or team
• A project or client engagement ends
• A security incident involves access compromise
• A third-party vendor contract expires or is terminated

16. Policy Enforcement

Violations of this policy will be addressed on a case-by-case basis. Repeated or intentional violations may result in:

• Immediate suspension of system access
• Disciplinary action up to and including termination
• Legal action where required

All violations are reported to the Security Lead and CEO.

17. Version History

End of Document