Corporate Policy

Access Control Policy

How RW Business Services decides who — and what — may reach the systems and data entrusted to it, including our clients' financial data and the systems we build and operate for them.

Purpose & scope

Define how access to systems and data is granted, authenticated, restricted, reviewed, and revoked. This policy expands the Identity & Access Management section of the Information Security Policy and uses the same definitions of Company Systems, Client Systems, and Client Data.

It applies to every system that stores or processes Restricted or Confidential data — RWBS's own platforms, accounts, repositories, databases, secret stores, and administrative endpoints, and any client-owned system RWBS is granted access to or operates on a client's behalf. It covers human users, machine and agent identities, and third-party processors.

This policy states the controls in force today. It does not claim controls RWBS does not operate.

Roles & responsibilities

The Owner is the accountable party for all access decisions: granting and revoking access, approving exceptions, performing access reviews, and maintaining this policy. Every person who performs work for RWBS is bound by this policy before receiving access to Restricted or Confidential data. Where a control requires a second party and none is available, the Owner records the compensating control instead. Security reports go to security@rw-businessservices.com.

Principles

Deny by default. Access is not granted unless there is a clear, current business need.
Least privilege. Each identity receives the minimum permission required for its function, and no more — including machine identities and the database role used by an application.
Unique identity, no shared credentials. Every person and every service authenticates as itself. Shared logins are prohibited, including logins issued by a client.
Client data is accessed only as authorized. RWBS reaches a client's data only to perform work that client has engaged it for, and only for as long as that engagement requires it.
Separation between clients. One engagement's credentials, repositories, and environments are never used to reach another client's data, and never commingled with RWBS's internal systems.
Separation of duty between proposing and approving. Automated agents may read data and propose changes to financial records; only an authenticated human session may approve and post them. This boundary is enforced structurally in the application, not by convention.
Restricted data is handled at the highest tier. Financial-account tokens, account identifiers, balances, transactions, statements, and client credentials are encrypted in transit and at rest, additionally encrypted at the application layer where they are stored, never written to logs in plaintext, and never exposed to client-side code.

Role-based access

Access is assigned by role rather than ad hoc. The roles in force are:

Role	Held by	Permissions
Owner / Administrator	The Owner (one named human account)	Full administrative access, granted through each platform's own role model (Google Workspace admin, GitHub owner, Vercel owner, Neon project owner, Plaid Dashboard admin).
Application runtime	An RWBS-operated application's service identity	Scoped OAuth tokens and a least-privilege database role sufficient to read and write that application's data. No platform-administration rights, no credential management.
Automation / agent identity	Scheduled routines and agents	Bearer-secret authentication to a fixed set of read-only and propose-only endpoints. Structurally cannot reach session-authenticated approval routes.
Client-environment operator	A named RWBS individual, on a client-issued account	Only the permissions that client has granted for the engagement, at the least privilege that accomplishes the work. Scoped to that client alone.
Third-party processor	Vendors listed in the Information Security Policy	Only the data required to deliver their service, under contract, governed by that vendor's own access controls.

RWBS presently has no employees or contractors, so the Owner is the only human identity. A Standard User role — least-privilege, with no production or Restricted-data access by default — is created before any first employee or contractor is onboarded, and the provisioning and revocation controls below apply to them in full from day one.

Identity and authentication

Centralized identity. Google Workspace is the primary identity provider. RWBS-operated applications authenticate users through Google OAuth SSO and restrict sign-in to the approved email domain. Platform accounts are federated to that identity through "Sign in with Google" wherever the vendor supports it; where a vendor or a client requires a local account, credentials are unique, high-entropy, and stored in the password manager.
Multi-factor authentication is mandatory on every account with access to Restricted or Confidential data: Google Workspace, Vercel, Neon, GitHub, the Plaid Dashboard, the secrets and password manager, and any client-issued account whose platform supports it. Phishing-resistant factors — passkeys, platform biometrics, or hardware security keys — are used wherever the platform supports them.
No credential sharing. Passwords, API keys, and tokens are never shared between identities, transmitted over chat or email, or committed to source control. Automated secret scanning runs on every repository — internal and client-facing — and blocks a commit containing credentials before it leaves the machine.
Machine authentication uses scoped OAuth tokens or bearer secrets, never a human's password. Secrets live only in a platform secret store or the password manager.

Access to client environments

Where a client grants RWBS access to their systems, that access is held to this policy:

RWBS requests a named individual account, never a shared client login, at the least privilege that accomplishes the engagement, with MFA enabled where the client's platform offers it.
Client-issued credentials are stored in the password manager, used only for that engagement, and never reused across clients.
RWBS does not copy Client Data out of the client's environment except as the engagement requires, and anything copied is classified and protected per the Information Security Policy.
Systems RWBS builds for a client hold their secrets in the client's own secret store, so operational control transfers with the system.
On completion or termination of an engagement, RWBS's access is revoked, shared secrets are rotated, and Client Data is returned or deleted per the Data Retention & Deletion Policy. RWBS asks the client to confirm revocation on their side.

Non-human and agent identities

Automated components authenticate with their own scoped secrets and are held to the same least-privilege standard as people:

Agent and routine identities are issued a bearer secret authorizing reading computed data and submitting proposals only. Approval endpoints require an authenticated human session and are not reachable with a bearer secret — so an automated component cannot approve its own proposal even if its secret is compromised.
Any destructive operation exposed to a machine identity routes through an out-of-band human approval gate.
Machine secrets are rotated on suspected exposure, on vendor change, at the end of a client engagement, and whenever the associated component is retired. Financial-account access tokens and application-layer encryption keys are treated as Restricted.

Provisioning, modification, and revocation

Provisioning. Access is requested against a named business need, approved by the Owner, granted at the least privilege that satisfies the need, and recorded.
Modification. When a role changes, access is re-scoped to the new need and any permission no longer required is removed at the same time — not deferred to the next review.
Revocation. Access is revoked promptly and no later than one business day after it is no longer needed — on separation, on completion or termination of a client engagement, on vendor termination, or on suspicion of compromise. Revocation includes disabling the account at the identity provider, removing platform role assignments, rotating any secret the identity could have observed, and invalidating active sessions.
Automation status. RWBS has no employees and therefore operates no automated de-provisioning tooling; revocation is a documented manual procedure executed by the Owner and completed within the interval above. Automated de-provisioning will be implemented alongside the first hire, when centralized user lifecycle management becomes meaningful.

Privileged and production access

Administrative access to production — financial databases, hosting project settings, secret stores, the Plaid Dashboard, and repository administration — is held only by the Owner, is protected by phishing-resistant MFA, and is exercised from a managed endpoint. Direct human queries against production financial data are limited to administration, investigation, and incident response; routine work goes through the application, where writes to the ledger pass through the double-entry writer and are captured in the append-only audit log.

Access review

The Owner performs a documented access review at least annually, and additionally whenever a role changes, a client engagement begins or ends, a vendor relationship changes, or an incident occurs.
A review enumerates, for every system in scope: the accounts that exist, the role each holds, the MFA status of each, every active machine identity and bearer secret, every client environment RWBS still holds access to, and every third-party integration with standing access. Anything without a current business need is removed during the review, not merely noted.
The outcome — date, systems reviewed, changes made — is recorded in the attestation log. The compliance monitoring agent carries the review as a recurring checklist item and escalates it if it comes due unaddressed.

Endpoint and remote access

Administrative access occurs from Owner-controlled devices running a supported operating system with full-disk encryption, automatic security updates, and a short screen-lock timeout. Devices are not shared, and Client Data is not stored on personal devices or removable media. All access to RWBS systems is over the public internet to vendor-managed TLS endpoints; RWBS operates no private network, VPN, or self-managed servers, so there is no internal network trust boundary to grant. Access decisions therefore rest on identity, MFA, and per-service authorization rather than network location.

Logging and monitoring

Security-relevant changes to financial data are written to an append-only audit log, immutable at the database. Platform authentication and deployment logs (Google, Vercel, GitHub, Neon, Plaid) are retained by those providers and are the record consulted during an investigation. Access to the Plaid Dashboard and to production systems is limited and monitored.

Exceptions

Any deviation from this policy must be recorded with its business justification, its compensating control, and an expiry date, and is re-evaluated at the next access review. Standing exceptions are not permitted for Restricted data or for Client Data.

Review & enforcement

This policy is reviewed and updated at least annually and whenever the business materially changes — notably on the first hire, and before RWBS stores multiple clients' data together in a self-service system, at which point per-tenant data isolation enforced at the database and multi-factor authentication before a client links a financial account become required controls. Failure to follow this policy is grounds for immediate revocation of the access concerned.