Access Control Policy

Governs how identities are established, authenticated, authorised, and reviewed across Finaisse systems. Subordinate to the Information Security Policy.

Policy owner	Security & Infrastructure Owner (Sekhar Prakash)
Applies to	All personnel, systems, and the Finaisse platform
Effective	2026-08-19 (v0.1 draft)
Review cadence	Annual + on major change
SOC 2	CC6.1, CC6.2, CC6.3

1. Purpose

Ensure that access to Finaisse systems and data is granted on a least-privilege basis, authenticated appropriately, and revoked promptly — and that tenant data is never accessible across customer boundaries.

2. Principles

• Least privilege — every human and service holds the minimum access required for its function, for the minimum necessary duration.
• Accountability — every access and privileged action is attributable and auditable.
• Tenant isolation — access controls enforce that no user or service in one tenant context can reach another tenant's data.

3. Human access

3.1 Authentication

• Source control (GitHub): organisation-wide 2FA is enforced.
• Staging / infrastructure (Railway): operator access via GitHub SSO.
• Management/admin portal: gated by Cloudflare Access with an admins-only policy (SSO); the portal holds no in-browser secret.
• Internal documentation site (this site, internal-docs.finaisse.com, and docs.finaisse.com): gated by Cloudflare Access, single Allow policy on membership of the finaisse-org GitHub organisation (GitHub is the only login method offered). Access therefore derives from the org member list, not from an email domain — removal from the organisation revokes access.
• Application (tenant) users: authenticated via JWT. 🎯 Target — multi-factor authentication for application users, especially admin/approver roles (F-23; owner: Security & Infrastructure Owner; expected with AWS production readiness).
• AWS account: 🎯 Target — AWS Identity Center (SSO) + enforced MFA, no standing IAM users except break-glass (part of the AWS build; F-22).

3.2 Authorisation

• Application authorisation is role-based (RBAC), enforced server-side on finance endpoints (deny-by-default; a request without the required permission is rejected). The permission catalogue and role grants are seeded per tenant.
• Administrative operations on tenants are performed only through the management portal, behind admins-only SSO, with operator actions logged.

3.3 Provisioning & deprovisioning

• Access is granted on documented business need, aligned to role.
• 🎯 Target — formal joiner/mover/leaver workflow with deprovisioning within a defined SLA (owner: Security & Infrastructure Owner). Today, personnel access is limited and granted/revoked directly by the owner; this becomes a documented workflow as the team grows.
• Removing a person from the finaisse-org GitHub organisation is the single action that revokes source-control access and internal-documentation access (the docs site authorises on org membership). It does not revoke Railway, AWS or application access, which are deprovisioned separately.

3.4 Access reviews

• 🎯 Target — quarterly review of access to production systems and source control, with removal of no-longer-needed grants. First formal review to be scheduled at AWS production readiness; until then, access is small in scope and owner-managed.
• The finaisse-org member list is the review artifact for both source control and the internal documentation site, since both authorise on it.

4. Service & machine access

• Inter-service communication on Railway uses the private network (.railway.internal); backends are not publicly exposed.
• Secrets (JWT signing key, storage credentials, API keys) are stored as environment variables in the platform's secret store, never in source. See Secure SDLC Policy and Data Classification Policy.
• 🎯 Target (AWS) — short-lived, rotated service credentials via a managed secrets service; per-service least-privilege IAM roles (F-12, F-18).

5. Tenant access isolation

• Data isolation is enforced by a dedicated database per customer.
• 🎯 Target — bind the request tenant identity to the authenticated JWT tenant claim, with a database-level backstop, closing the current header-trust gap (F-01; a production go-live blocker). Related: tenant-scoping of workflow visibility (F-38).

6. Enforcement & exceptions

Access granted in violation of this policy is revoked on discovery. Exceptions require owner approval with a recorded expiry.

Revision history

Version	Date	Author	Change
0.1	2026-08-19	Security & Infrastructure Owner	Initial draft