Skip to Content
Security PoliciesAccess Control Policy

Access Control Policy

FieldValue
Document IDPOL-002
Version1.0
Effective Date2026-04-08
Next Review Date2027-04-08
ClassificationInternal
OwnerInformation Security Officer
Approved ByCEO, Paylithix Inc.
Parent PolicyInformation Security Policy (POL-001)

1. Purpose

This policy defines the access control requirements for the Gatelithix Gateway Cardholder Data Environment (CDE) and connected systems. It ensures that access to cardholder data and CDE resources is restricted to authorized personnel on a need-to-know basis, in compliance with PCI DSS 4.0.1 Requirements 7 and 8.

2. Scope

This policy applies to all access mechanisms for CDE and connected systems:

  • GCP Console and API access to the gatelithix-pci and gatelithix-core projects
  • Auth0 tenant administration and user management
  • Cloud SQL database access (PCI and Core instances)
  • Cloud KMS key access
  • Cloud Run service deployment and configuration
  • Application-level access via the Gatelithix Dashboard and API
  • Source code repositories containing CDE components (apps/vault/)
  • CI/CD pipelines that deploy to CDE infrastructure

3. Roles and Responsibilities

RoleResponsibility
Information Security OfficerApproves CDE access requests; conducts quarterly access reviews; maintains access control policy
Engineering LeadProvisions/deprovisions GCP IAM and Auth0 accounts; implements RBAC controls; maintains CODEOWNERS
People OperationsInitiates onboarding/offboarding workflows; coordinates with Engineering for account provisioning
All PersonnelSafeguard credentials; report unauthorized access; comply with access policies

4. Policy Statements

4.1 Least Privilege Principle

  1. All access to CDE resources shall be granted based on the minimum permissions required for the individual’s job function (PCI DSS 7.1.1).
  2. Default access to CDE resources is deny-all. Access is granted only through explicit approval.
  3. No individual shall have standing administrative access to production CDE systems unless their role specifically requires it.
  4. Service accounts used by CDE workloads (e.g., the vault Cloud Run service identity) shall have permissions scoped exclusively to required resources (Cloud KMS decrypt, Cloud SQL connect).

4.2 Application Role Definitions (Auth0 RBAC)

The Gatelithix Dashboard and API enforce role-based access control through Auth0. The six defined roles are:

RoleDescriptionCDE AccessDashboard Access
platform_adminPaylithix internal: full platform managementFull (GCP IAM + Auth0)All pages, all merchants
platform_viewerPaylithix internal: read-only platform viewRead-only (GCP IAM)All pages read-only, all merchants
iso_adminISO partner: manage their merchant portfolioNone (API only)ISO merchants, pricing, residuals
iso_viewerISO partner: read-only view of their portfolioNoneISO merchants read-only
merchant_adminMerchant: manage their own configurationNone (API only)Own merchant pages, API keys, webhooks
merchant_viewerMerchant: read-only view of their dataNoneOwn merchant pages read-only

CDE access (GCP Console, Cloud SQL, Cloud KMS, vault deployment) is restricted to platform_admin and platform_viewer roles, enforced through GCP IAM bindings — not through the application layer.

4.3 GCP IAM Access Levels

Access LevelGCP RolesGranted ToApproval Required
CDE Adminroles/owner on gatelithix-pci projectCEO, ISOCEO approval
CDE Deployerroles/run.admin, roles/cloudsql.client on PCI projectEngineering Lead, CI/CD service accountISO approval
CDE Viewerroles/viewer on gatelithix-pci projectPlatform viewers, QSA (during assessment)ISO approval
KMS Operatorroles/cloudkms.cryptoKeyEncrypterDecrypterVault service account onlyISO + Engineering Lead approval
Core Adminroles/owner on gatelithix-core projectCEO, ISO, Engineering LeadISO approval
Core Deployerroles/run.admin on core projectEngineering, CI/CD service accountEngineering Lead approval

4.4 Account Provisioning

  1. New account requests must be submitted to the ISO with: (a) the individual’s name and role, (b) specific systems and access levels required, (c) business justification, and (d) expected duration if temporary.
  2. The ISO reviews the request against the least-privilege principle and approves or denies within 2 business days.
  3. Upon approval, the Engineering Lead provisions the account in GCP IAM and/or Auth0 within 1 business day.
  4. A provisioning record is created in the access log documenting: requester, approver, systems granted, date, and role.
  5. The new user receives a unique user ID (email-based identity via Google Cloud Identity or Auth0).
  6. Shared or group accounts are prohibited for interactive access to CDE systems.

4.5 Account Deprovisioning

  1. When personnel leave the organization or change roles, People Operations shall notify the ISO within 1 business day.
  2. CDE access shall be revoked within 24 hours of termination or role change (same business day for involuntary termination).
  3. Deprovisioning includes: GCP IAM binding removal, Auth0 account deactivation, API key revocation, VPN/SSH key removal, and repository access removal.
  4. The Engineering Lead confirms deprovisioning completion and records it in the access log.

4.6 Authentication Requirements

  1. Multi-factor authentication (MFA) is required for all interactive access to:
    • GCP Console (enforced via Google Cloud Identity)
    • Auth0 Dashboard (enforced via Auth0 tenant settings)
    • Stripe Dashboard (enforced via Stripe settings)
    • GitHub repositories (enforced via GitHub organization settings)
  2. Password requirements for Auth0 accounts:
    • Minimum length: 12 characters
    • Complexity: at least one uppercase, one lowercase, one digit, one special character
    • Password history: last 4 passwords cannot be reused
    • Maximum age: 90 days (PCI DSS 8.3.9)
  3. Session management:
    • Idle session timeout: 15 minutes for CDE administrative sessions (PCI DSS 8.2.8)
    • Maximum session duration: 12 hours
    • Re-authentication required after session expiration
  4. API key authentication:
    • API keys use cryptographically random tokens (minimum 128 bits of entropy)
    • Keys are scoped to specific merchants and permission sets
    • Keys are stored as bcrypt hashes; plaintext is shown only at creation time
    • Key rotation is recommended every 90 days; mandatory annually

4.7 Account Lockout

  1. Interactive accounts shall lock after 10 consecutive failed authentication attempts (PCI DSS 8.3.4).
  2. Locked accounts remain locked for a minimum of 30 minutes or until unlocked by an administrator.
  3. Failed authentication attempts are logged in the audit trail with timestamp, source IP, and account identifier.

4.8 Quarterly Access Review

  1. The ISO shall conduct a formal access review at least quarterly (PCI DSS 7.2.5).
  2. The review shall cover:
    • All GCP IAM bindings on both gatelithix-pci and gatelithix-core projects
    • All Auth0 user accounts and role assignments
    • All active API keys and their scopes
    • All CI/CD service account permissions
    • Cloud KMS key IAM bindings
  3. For each account, the reviewer confirms: (a) the account is still needed, (b) the access level is appropriate for current role, (c) MFA is enabled.
  4. Accounts that are no longer needed or have excessive permissions are remediated within 5 business days.
  5. The review is documented with: reviewer name, date, accounts reviewed, findings, and remediation actions taken.
  6. Review records are retained for at least 12 months.

4.9 Remote Access

  1. All remote access to CDE systems occurs over encrypted channels (TLS 1.2+ or SSH).
  2. Direct SSH access to CDE systems is not available (Cloud Run is serverless with no SSH).
  3. Cloud SQL access requires the Cloud SQL Auth Proxy with IAM authentication — no direct database connections with static passwords.
  4. All remote access sessions are logged.

4.10 Service Account Controls

  1. Service accounts used by CDE workloads shall have dedicated identities (one per service, no sharing).
  2. Service account keys shall not be exported or stored locally. Workload identity federation is used for Cloud Run services.
  3. Service accounts shall not have interactive login capabilities.
  4. Service account permissions are reviewed as part of the quarterly access review.

5. Compliance and Enforcement

  1. Violations of this policy, including sharing credentials, bypassing MFA, or accessing systems beyond authorized scope, shall be reported to the ISO.
  2. Unauthorized access to CDE systems shall be treated as a security incident and handled per the Incident Response Plan.
  3. Intentional policy violations may result in disciplinary action up to and including termination.

7. Document History

VersionDateAuthorChanges
1.02026-04-08Information Security OfficerInitial policy creation
Information Security PolicyNetwork Security Policy