Access Control Policy

1. Purpose & Scope

This policy defines how Joliez Agency Inc. (“Joliez Agency”) grants, modifies, reviews, and revokes access to production systems, sensitive consumer data, and the infrastructure that supports them. It applies to every employee, contractor, automated process, and third-party integration that touches a production asset.

Systems in scope: the Joliez Agency web application (talent, employee, client, admin, superadmin, corporate portals), the production database, application file-system stores, the hosting control panel, the Plaid and Stripe dashboards, the domain registrar, the corporate email tenant, and any source-control or deployment pipeline that can ship to production.

2. Principles

• Least privilege. Each identity receives only the permissions required for its role — nothing more.
• Need-to-know. Access to consumer PII or financial data is granted only when the role’s job function requires it, and only to the fields it requires.
• Zero trust. Every privileged request is re-evaluated. There is no “trusted network.” Authentication, device posture, IP origin, and step-up freshness are checked at every gated action.
• Segregation of duties. The user who initiates a financial action is not the user who approves it, where the operation supports it (payroll, banking changes, role elevation).
• Auditability. Every access decision — grant, deny, escalation — is logged with actor, action, target, and timestamp.

3. Roles & Permissions (Role-Based Access Control)

Application access is gated by a centralized role-check evaluated on every request. Every page and API endpoint that touches sensitive data declares the roles that may invoke it.

Role assignment is performed only by an existing superadmin. The assignment is logged in the application audit trail with the granting user, target user, prior role, new role, justification, and timestamp.

4. Zero-Trust Enforcement

• Per-request authentication. Every request passes through a centralized authentication check and a role gate. Long-lived “remember me” sessions are not used for administrative accounts.
• Device binding. Administrative sessions are bound to a registered, admin-approved device via an HMAC-signed cookie. An unknown device cannot exercise gated actions even with valid credentials.
• IP allow-list. Administrative roles can only authenticate from CIDR ranges explicitly configured by the CTO.
• Per-action WebAuthn step-up. Every privileged write (payroll, banking, PII reveal, role change) requires a fresh WebAuthn assertion within a 5-minute window. See the Multi-Factor Authentication Policy.
• Phishing-resistant MFA for consumers before Plaid Link. Every consumer must complete a WebAuthn ceremony at the consumer pre-flight MFA gate before any Plaid Link launch.
• No implicit trust by network location. The application makes no security decision based on internal vs. external network origin. Loopback and private addresses are treated like any other client.

5. Non-Human Authentication

• OAuth bearer tokens. Plaid API access uses short-lived bearer credentials issued by Plaid and stored only in server-side configuration (never in the browser, never in the database, never in source control).
• API keys with TLS pinning. Stripe and other payment-rail integrations use restricted API keys. All outbound calls use TLS 1.2+ with full certificate verification enabled.
• SMTP over authenticated TLS. Outbound mail uses authenticated SMTP-AUTH over TLS to the configured mail relay.
• Webhook signing. Inbound webhooks (Plaid, Stripe) are verified against the provider’s signing secret before any state change is performed.
• Secret rotation. Non-human secrets are rotated at least annually, and immediately upon any suspected exposure, employee separation with prior access, or vendor advisory.
• No shared interactive logins. Service accounts and machine identities cannot be used for interactive login to the application.

6. Provisioning

• Access is requested through the superadmin portal by a manager and approved by the CEO or CTO.
• The new user receives the minimum role required for their function.
• Production access is contingent on enrollment of at least one phishing-resistant authenticator (passkey or hardware key). See the MFA Policy.
• The provisioning event is recorded in the application audit log and in the access-review register.

7. Modification & De-Provisioning

Access changes are automated through the application’s user-lifecycle subsystem and authentication layer:

• Role change. A superadmin updates the user’s role; the change takes effect on the next request via the centralized role check. The prior role’s grants are immediately invalid.
• Lock / suspend. A user can be locked with a documented reason (admin_manual, compliance_review, verification_pending, policy_hold, payment_hold, pending_onboarding, pending_documents). A locked user cannot complete authentication.
• Termination. Termination status flags (terminated_talent, terminated_employee, terminated_client) automatically block all subsequent logins at the authentication layer.
• Within four business hours of separation the CTO additionally: revokes all WebAuthn credentials for the user, revokes trusted devices, removes IP allow-list entries, invalidates active sessions, and rotates any infrastructure secrets the user could have memorized.
• The de-provisioning event is recorded in the access-review register with the performing user, target user, statuses cleared, and timestamp.

8. Periodic Access Reviews

Each review is recorded with the date, reviewer, list reviewed, changes made, and approving signature. Records are retained for 24 months.

9. Logging & Audit

• Authentication events are recorded in the application audit log (success, failure, lockout, password change).
• Device and WebAuthn events are recorded in the device-binding audit log (enrollment, approval, assertion success/failure, gate denial).
• Privileged data access (PII reveal, payroll execution, banking write) is recorded with the actor, target user, fields touched, and timestamp.
• Logs are retained for at least 13 months and reviewed for anomalies on a weekly cadence by the CTO.

10. Physical Access

Production infrastructure is hosted by a managed provider with SOC 2 / ISO 27001-certified data centers. Joliez Agency staff have no physical access to production hardware. Employee endpoint devices that can reach administrative consoles must use full-disk encryption (FileVault / BitLocker), screen-lock within 5 minutes of inactivity, and biometric or strong-passphrase unlock.

11. Third-Party & Vendor Access

Third parties receive access only under a written agreement that includes confidentiality, breach-notification, and minimum-security obligations. Access is scoped to the smallest set of resources required, time-boxed, and reviewed at expiration. Plaid receives only the data required to perform the API call invoked by the consumer and is bound by Plaid’s own end-user services agreement.

12. Exceptions

Exceptions to this policy must be requested in writing to the CEO, must include a compensating control and an expiration date no longer than 30 days, and are logged in the policy exception register. No exception may waive role-based gating or MFA for any account with access to consumer financial data.

13. Annual Review & Change Log

This policy is reviewed at least once per calendar year by the CEO and CTO, or sooner upon any material change to in-scope systems, a security incident, or a regulatory update (GLBA, CCPA/CPRA, IRS, Plaid Production Requirements).