Access Control Policy

Organization: 8 West Ventures, LLC, doing business as 8 West IT
Covered application: Coastmark, part of the 8 West IT 365 suite
Document classification: Public compliance document
Version: 1.0
Effective date: August 5, 2026
Policy owner: Chief Technology Officer
Security contact: Frank Gonzalez, CTO, frank@8westventures.com
Review cycle: At least annually and after a material security, regulatory, vendor, identity-provider, or architectural change

Approval record

This policy becomes effective only when approved by authorized management. Approval confirms that management accepts the access-control requirements, assigns the stated responsibilities, and will provide resources for implementation, evidence retention, and continuous improvement.

Approval status: Approved

Approved by: Frank Gonzalez
Title: Chief Technology Officer (CTO)
Approval date: August 5, 2026
Next review date: August 4, 2027

1. Purpose

This policy establishes how 8 West Ventures, LLC ("8 West IT") requests, approves, provisions, changes, reviews, monitors, and revokes logical and physical access to Coastmark and the systems that support it. Its purpose is to prevent unauthorized access to customer financial information, personal information, authentication material, payment data, Plaid-sourced financial data, source code, infrastructure, and other business information.

The policy is informed by the access-control, account-management, least-privilege, identification, authentication, and audit principles in NIST Special Publication 800-53 Revision 5.1 and by Plaid's current requirements for authorized users, legitimate business need, role-based permissions, prompt termination, credential protection, and monitoring. These references guide the program; this policy does not claim certification under any framework.

2. Scope

This policy applies to:

• employees, officers, contractors, temporary workers, service providers, and other people who access 8 West IT systems or information;
• Coastmark production, staging, development, testing, backup, and recovery environments;
• Microsoft Entra, 8 West ID suite SSO, email, source control, cloud hosting, databases, containers, payment providers, banking providers, Plaid, Stripe, monitoring, support, and administrative consoles;
• customer, workforce, privileged, service, integration, emergency, and machine identities; and
• company-controlled endpoints, facilities, records, credentials, cryptographic secrets, and physical locations used to administer Coastmark.

Third-party systems are subject to this policy to the extent that 8 West IT can configure, approve, review, or revoke access to them.

3. Access-control principles

Access decisions shall follow these principles:

• Deny by default: access is not granted unless it is explicitly authorized.
• Least privilege: each identity receives only the permissions necessary for approved duties.
• Legitimate business need: access to customer or provider data requires a current, documented business purpose.
• Unique accountability: workforce and privileged actions must be attributable to an individual identity wherever the system supports it.
• Role-based authorization: standard roles shall be used instead of one-off permissions when practical.
• Tenant isolation: access to Coastmark records is constrained to the active organization and may not cross tenant boundaries.
• Separation of duties: incompatible approval, administration, payment, reconciliation, deployment, and audit responsibilities shall be separated when practical or subject to documented compensating review.
• Time limitation: temporary, vendor, support, and emergency access expires when the approved task or period ends.
• Prompt revocation: access is removed when employment, affiliation, entitlement, duty, or business need ends.

4. Roles and responsibilities

Executive management

Executive management approves this policy, accepts material residual risk, and ensures that adequate resources are available to operate the access-control program.

Chief Technology Officer

The Chief Technology Officer (CTO), or a documented delegate, owns this policy and is responsible for:

• approving privileged, production, source-code administration, payment-provider, and banking-provider access;
• maintaining the inventory of critical systems, roles, and privileged identities;
• reviewing privileged and production access at least quarterly;
• ensuring that access changes and exceptions are documented;
• coordinating prompt revocation and security response; and
• retaining evidence appropriate to the sensitivity of the access.

Organization owners

A Coastmark organization owner approves membership and role changes within that organization, protects the owner role, reviews team access, and deactivates access that is no longer required. Coastmark must prevent removal or demotion of the only active owner unless ownership is transferred through an approved process.

System and data owners

System and data owners define allowable roles, approve access based on job need, identify incompatible duties, participate in access reviews, and validate that access remains appropriate.

Users

Users must protect their authenticators, use only their assigned accounts, complete required security training, report suspected compromise promptly, and access information only for authorized business purposes. Users may not approve their own privileged access or share credentials.

5. Identity and account requirements

• Every workforce user shall use a unique identity issued or federated through an approved identity provider.
• Shared interactive accounts are prohibited unless a provider makes individual identities impossible and the CTO documents the business need, authorized users, credential custody, monitoring, and rotation process.
• Generic or shared email addresses may not be used to conceal the person responsible for an administrative action.
• Test identities must be clearly identified, restricted to non-production environments, and must not use production credentials or production customer data unless specifically approved and protected.
• Service, integration, and machine identities must have an owner, purpose, environment, approved privileges, credential location, and review date.
• Dormant, duplicate, orphaned, expired, and unnecessary accounts shall be disabled or removed.

6. Account lifecycle

Request and approval

An access request must identify the person or service, system, requested role or permissions, organization or data scope, business justification, approving owner, and any expiration date. Privileged or production access also requires CTO or delegated security approval. The requester may not be the sole approver of their own privileged access.

Provisioning

Access shall be provisioned from an approved request using the least-privileged standard role. The person provisioning access must verify the intended identity, organization, environment, and role before activation. Initial or recovery credentials must be delivered through an approved secure channel and changed or invalidated as applicable.

Role or duty changes

When a user changes duties, unnecessary access shall be removed before or when new access is granted. A role change may not silently preserve legacy privileges that no longer have a business need.

Termination and suspension

Access must be disabled promptly when employment, contracting, affiliation, suite entitlement, or legitimate business need ends. Suspected misuse, credential compromise, legal direction, or a material security risk may require immediate suspension. Revocation includes active sessions, identity-provider access, Coastmark memberships, provider dashboards, source control, cloud consoles, remote access, tokens, keys, and physical credentials as applicable.

Records

Requests, approvals, provisioning, role changes, deactivations, and review dispositions shall be recorded in an approved ticket, audit event, access register, provider log, or other durable evidence source.

7. Authentication controls

• Coastmark workforce access shall use an approved federated sign-in path. Microsoft Entra OIDC is the invite-only sign-in path; 8 West ID suite SSO may be used only when its signing and entitlement controls are enabled and configured.
• Production demo authentication must remain disabled.
• Multi-factor authentication (MFA) is required for workforce access to production infrastructure, source-code administration, identity providers, email administration, Plaid, Stripe, cloud consoles, and other systems that store, transmit, or administer Restricted information.
• Plaid Dashboard users must use two-factor authentication or approved SSO where the account plan and provider support it. Recovery codes must be stored securely and separately from primary credentials.
• Authentication secrets, recovery codes, API credentials, and session tokens may not be sent through unapproved plaintext channels or stored in source code, tickets, chat, or shared documents.
• Production sessions shall use secure, encrypted, HTTP-only cookies with an appropriate SameSite setting and shall be invalidated at logout, revocation, or other security-relevant termination events where supported.
• Repeated authentication failures and security-relevant denials shall be rate-limited, alerted, or logged as appropriate without recording passwords, complete tokens, or provider secrets.

8. Coastmark authorization and tenant isolation

Coastmark access shall use the application's standard organization roles:

• Owner: organization administration and the broadest approved business access;
• Billing: operational accounting, invoicing, payment, and banking duties permitted by the application; and
• Viewer: read-oriented access with restricted mutation and administrative capabilities.

Role enforcement must occur on the server and may not rely only on hidden navigation or client-side controls. Sensitive actions shall verify the authenticated user, active organization membership, active status, role, and record ownership or organization scope.

All tenant-owned records must retain application organization scopes and PostgreSQL row-level security. The runtime database role may not bypass row-level security. Public invoice, customer portal, payment return, webhook, and Plaid callbacks must resolve opaque identifiers to the correct organization before tenant context is applied. A feature, migration, support operation, or troubleshooting step may not disable tenant isolation for convenience.

9. Privileged and production access

• Privileged access shall be limited to named individuals whose current duties require it.
• Users shall use non-privileged accounts or roles for routine work and elevate only for an approved administrative task where the system supports separation.
• Production shell, database administration, deployment, secret-management, and container-host access require strong authentication and an approved access path.
• Production PostgreSQL must not publish a host port, and the Coastmark web service must remain bound to host loopback behind approved ingress.
• Direct production data changes are prohibited unless an approved operational or incident procedure requires them. Posted journal entries, journal lines, and audit events remain immutable; corrections use approved reversing or compensating entries.
• Privileged actions shall be logged where technically supported and reviewed when anomalous, security-relevant, or part of a periodic access review.

10. Service accounts, API credentials, and secrets

• Each service account, OAuth client, webhook secret, API key, and machine credential must have a documented owner and approved purpose.
• Credentials shall be scoped to the minimum environment, API, permission, account, and duration supported by the provider.
• Production and non-production credentials must be separated.
• Secrets shall be stored only in approved secret or environment configuration and must never be committed to source control or exposed in logs, screenshots, support records, complete webhook payloads, or customer documents.
• Credentials must be rotated after suspected exposure, when an authorized custodian leaves or changes duties, when a provider requires it, or on a risk-based schedule.
• Unused credentials and integrations shall be revoked promptly.

11. Plaid and financial-data access

Access to Plaid services, Plaid-sourced End User Data, bank-account information, access tokens, and related support records is Restricted and requires a legitimate business need.

• Plaid Dashboard access shall be granted only to specifically authorized personnel using named accounts, the least-privileged available team permissions, and MFA or approved SSO.
• Plaid team membership, permission configuration, and MFA status shall be reviewed at least quarterly and after a role change, termination, suspected misuse, or material integration change.
• Plaid Client IDs, secrets, access tokens, processor tokens, and webhook verification material shall be encrypted in transit and at rest and accessible only to approved application services or administrators.
• End User Data may be accessed only for the Coastmark use case authorized by the customer and may not be used for personal purposes, unrelated analytics, credential testing, or any undisclosed purpose.
• Access to customer banking functions within Coastmark shall require an active organization membership and an authorized role. Cross-organization bank access is prohibited.
• Suspected unauthorized access to Plaid services or End User Data must be contained, investigated, documented, and reported to Plaid or other parties when contractually or legally required.

12. Third-party, contractor, and remote access

• Third-party access requires a sponsor, approved scope, confidentiality and security obligations, an expiration date, and monitoring proportional to risk.
• Vendor and contractor access shall use individual identities where available and may not be shared among vendor personnel.
• Remote administrative access must use encrypted protocols, strong authentication, approved devices, and the narrowest network and system scope practical.
• Support access to customer data requires a documented support purpose and must end when the support task is complete.
• The sponsor or system owner shall review and revoke third-party access when the engagement, task, or contract ends.

13. Separation of duties and compensating review

Where staffing allows, different people should request, approve, provision, and review privileged access. Payment initiation, refund approval, reconciliation, deployment, security-log administration, and audit review should be separated when practical.

When a small-team constraint prevents full separation, the CTO shall document the conflict, apply the strongest practical technical restriction, retain detailed evidence, and require an independent retrospective review by another authorized person. The same individual may not silently authorize and conceal their own privileged activity.

14. Periodic access reviews

• The CTO or delegate shall review privileged, production, source-control administration, cloud, Plaid, Stripe, identity-provider, and other critical-system access at least quarterly.
• Organization owners shall review active Coastmark memberships and roles at least quarterly and after material staffing or responsibility changes.
• Service accounts, integration credentials, API keys, and emergency access shall be reviewed at least quarterly for owner, purpose, privilege, use, and continued necessity.
• Reviewers must verify identity, employment or affiliation, active business need, role, organization and data scope, MFA status where available, last use or activity where available, and expiration.
• Review dispositions shall record access retained, reduced, disabled, removed, or escalated, including the reviewer and review date.

15. Logging, monitoring, and alerting

Security-relevant access events shall be logged and retained in proportion to risk. Relevant events include authentication failures, session termination, membership invitation or deactivation, role changes, privileged operations, access denials, provider team changes, credential rotation, production access, webhook verification failure, and anomalous banking or payment activity.

Logs must identify the acting identity, event, time, result, and relevant system or organization without recording passwords, complete access tokens, API secrets, session cookies, complete provider payloads, or unnecessary customer financial data. Access logs and audit evidence shall themselves be restricted from unauthorized modification or deletion.

Alerts or investigations shall be initiated for suspected credential compromise, repeated denials, unexpected privilege changes, cross-tenant access attempts, unusual provider access, or other activity inconsistent with the approved business purpose.

16. Emergency and break-glass access

Emergency access may be used only to protect life, safety, data, service availability, legal obligations, or material business operations when the ordinary approval path cannot meet the urgency.

Emergency access must be time-limited, strongly authenticated, logged, and restricted to the minimum required action. The user must document the reason, systems accessed, actions taken, data affected, and time access ended. The CTO or an independent authorized reviewer shall review the activity promptly after the event, and emergency credentials shall be disabled or rotated after use.

17. Endpoint and physical access

Devices used for privileged or production administration must use supported operating systems, full-disk encryption, screen locking, endpoint protection, host firewall controls, security updates, and MFA. Lost, stolen, or compromised devices must be reported promptly and have access revoked or remotely protected where supported.

Physical access to offices, equipment, backup media, and records containing Restricted information shall be limited to authorized personnel based on job need. Visitors and maintenance personnel must be supervised where they could access Restricted information or administrative systems. 8 West IT relies on approved cloud and colocation providers for physical controls over hosted production infrastructure and reviews relevant provider assurances as part of vendor management.

18. Exceptions

An exception must be documented before use and identify the requirement, business reason, affected systems and data, risk, compensating controls, owner, approver, start date, and expiration date. The CTO and applicable system or data owner must approve the exception. Exceptions shall be time-limited, reviewed before expiration, and may not waive a legal or contractual requirement.

19. Access-related security incidents

Suspected unauthorized access, privilege abuse, credential exposure, cross-tenant access, or inappropriate use of customer or provider data must be reported immediately through the incident-response process. Response actions may include session termination, account suspension, credential rotation, access-token revocation, provider notification, preservation of evidence, customer or regulator notification, and retrospective access review.

20. Control evidence and minimum cadence

Evidence shall be retained according to the Information Security Policy, applicable contracts, legal obligations, and business need, and shall be provided only to authorized reviewers.

21. Enforcement and review

Violations may result in access suspension or revocation, disciplinary action, contract remedies, customer or provider notification, and legal action as appropriate. Deliberate attempts to bypass authentication, authorization, tenant isolation, audit logging, or provider controls are prohibited.

This policy shall be reviewed at least annually and after a material incident, access-control failure, regulatory change, provider requirement, identity-provider change, or architectural change. Revisions require management approval, and prior versions and approval records must be preserved.

22. References

• Plaid Developer Policy, including responsibility for authorized users, legitimate business need, role-based permissions, prompt termination, credential protection, reasonable access controls, and monitoring: https://plaid.com/legal/
• Plaid Dashboard account security guidance for two-factor authentication, SSO, and team-member status: https://plaid.com/docs/account/security/
• NIST Special Publication 800-53 Revision 5.1, including AC-2 Account Management, AC-3 Access Enforcement, AC-5 Separation of Duties, AC-6 Least Privilege, IA-2 Identification and Authentication, IA-5 Authenticator Management, and AU audit controls: https://doi.org/10.6028/NIST.SP.800-53r5
• Coastmark Information Security Policy, current approved version.