Coastmark — 8 West IT 365
Back to Coastmark

Information Security 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, or architectural change

Approval record

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

Approved by: Frank Gonzalez
Title: CTO
Approval date: August 5, 2026
Next review date: August 4, 2027

1. Purpose

This policy establishes the administrative, technical, and physical safeguards used by 8 West Ventures, LLC ("8 West IT") to protect the confidentiality, integrity, and availability of information processed by Coastmark. It defines a risk-based security program for customer financial data, personal information, authentication material, payment information, source code, infrastructure, and other business information.

The program is informed by the NIST Cybersecurity Framework 2.0 functions - Govern, Identify, Protect, Detect, Respond, and Recover - and by the security obligations in Plaid's Developer Policy. These references guide the program; this policy does not claim certification under any framework.

2. Scope

This policy applies to:

  • all employees, contractors, service providers, and other authorized users with access to 8 West IT systems or data;
  • Coastmark production, staging, development, backup, and administrative environments;
  • endpoints used to administer or develop Coastmark;
  • customer and end-user information received directly or through providers including Plaid, Stripe, Microsoft, and other approved vendors; and
  • source code, credentials, logs, documents, databases, network services, and recovery data supporting Coastmark.

Third parties must protect 8 West IT information in a manner consistent with contractual requirements, applicable law, and the sensitivity of the information.

3. Security governance and responsibilities

3.1 Executive management

Executive management approves this policy, determines acceptable business risk, assigns adequate resources, and reviews material risks and security incidents. Risks outside approved tolerance require documented treatment or explicit management acceptance.

3.2 Chief Technology Officer

The Chief Technology Officer (CTO) is the Information Security Officer for Coastmark and is accountable for:

  • maintaining this policy and related standards, procedures, and evidence;
  • maintaining the security risk register and coordinating risk treatment;
  • approving production and sensitive-data access;
  • coordinating vulnerability management, incident response, recovery, and provider notifications;
  • reviewing material vendors and architectural changes; and
  • reporting significant risks and incidents to executive management.

3.3 System and data owners

System and data owners classify information, approve access based on job need, ensure retention and deletion requirements are applied, and participate in risk and incident reviews.

3.4 Workforce members and contractors

Authorized users must follow this policy, protect credentials and devices, complete required security awareness activities, and report suspected loss, misuse, phishing, malware, unauthorized access, or data disclosure immediately to the CTO.

4. Risk management

8 West IT shall maintain an information-security risk process appropriate to its size, services, and data. The CTO shall:

  • perform and document a security risk review at least annually;
  • reassess risk before material changes to authentication, payment, banking, hosting, data flows, or key vendors;
  • record identified assets, threats, vulnerabilities, likelihood, impact, current safeguards, owner, treatment, and due date in a risk register;
  • treat risk by mitigating, transferring, avoiding, or explicitly accepting it; and
  • monitor open risks until closure, with material or overdue items reported to executive management.

Security exceptions must be documented, time-limited, approved by the CTO and the applicable business owner, and reviewed before expiration. An exception may not waive a legal or contractual requirement.

5. Asset management and data classification

Information and systems shall have an owner and a classification based on sensitivity and business impact:

  • Restricted: authentication credentials, encryption keys, Plaid access tokens and secrets, payment-provider secrets, bank-account details, sensitive personal information, and incident evidence containing such data.
  • Confidential: customer financial records, invoices, receipts, bank transactions, audit records, contracts, non-public source code, internal architecture, and business records.
  • Internal: routine operational information not intended for public release.
  • Public: information approved for public distribution.

Restricted and Confidential information shall be collected only for an authorized purpose, limited to what is reasonably necessary, accessed only by authorized persons or services, and retained only for the period established in Section 14.

6. Identity and access management

Access shall be based on unique identities, least privilege, job responsibility, tenant boundary, and business need.

  • Production and administrative access must use individual accounts. Shared interactive accounts are prohibited unless technically unavoidable, formally approved, and subject to compensating logging and credential controls.
  • Multi-factor authentication (MFA) is required for workforce access to production infrastructure, source-code administration, cloud consoles, payment and banking provider dashboards, email administration, and other critical systems that store or process consumer financial data.
  • Coastmark users must authenticate through an approved identity provider. MFA must be enforced for consumer access before Plaid Link is made available in production.
  • Application authorization must use role-based access controls and organization scoping. Database row-level security and application tenant scopes may not be disabled to simplify a feature.
  • Privileged access must be limited, separately approved, and used only when needed. Production data access must be bounded and auditable.
  • The CTO or delegate shall review privileged and production access at least quarterly and document the result.
  • Access must be removed promptly when no longer required, no later than one business day after a normal separation and immediately for an involuntary or security-related separation.
  • Service credentials must be scoped to the minimum permissions available, stored separately from source code, and rotated after suspected exposure, a relevant personnel change, or provider requirement.

7. Authentication and session security

Coastmark production authentication shall use approved OIDC or suite SSO paths. Demo authentication must remain disabled in production. Production sessions must use encrypted, secure, HTTP-only cookies with an appropriate SameSite setting. Authentication failures and security-relevant denials shall be rate-limited or logged as appropriate without recording credentials, tokens, or complete identity-provider payloads.

8. Encryption, secrets, and key management

  • Network communication carrying Restricted or Confidential information must use HTTPS with TLS 1.2 or higher and a valid certificate. Insecure certificate validation and self-signed production certificates are prohibited.
  • Plaid access tokens must be encrypted at the application layer before storage. Coastmark must not store the bank credentials entered by an end user in Plaid Link.
  • Databases, private-file storage, backups, administrative endpoints, and portable devices containing Restricted or Confidential information must use encryption at rest appropriate to the platform. Before management represents this control as implemented, the CTO must verify and retain evidence of the underlying storage encryption.
  • Secrets must not be committed to source control, embedded in client-side code, sent through unapproved channels, or written to application logs. Production secret files must be readable only by the required administrative or runtime identity.
  • Encryption keys and provider secrets must be logically separated from the encrypted data and restricted to authorized services and administrators.
  • Keys and secrets must be rotated at least annually where supported, and immediately after confirmed or suspected compromise. Rotation must include validation, rollback planning, and revocation of the prior value.

9. Infrastructure and network security

8 West IT shall apply defense in depth to Coastmark infrastructure.

  • Public traffic must terminate at an approved TLS ingress. Application services should be exposed only on the interfaces and ports required for operation.
  • Production databases must remain on private networks and must not publish database ports to the internet or host network.
  • Hosts, containers, services, and network rules must follow least-functionality and least-privilege principles. Runtime services must not run with unnecessary privilege, and available platform protections such as no-new-privileges must be enabled.
  • Production, development, and test data and credentials must be separated. Production data may not be copied into lower environments unless approved, minimized, and protected to the same standard.
  • Supported software versions and security patches must be maintained. Unused accounts, services, packages, ports, and credentials must be removed or disabled.
  • Infrastructure changes must follow the change-management and release controls in Section 11.

10. Endpoint and workforce security

Endpoints used to access production or Restricted information must:

  • use supported operating systems with automatic security updates enabled;
  • use full-disk encryption, anti-malware or endpoint protection, a host firewall, automatic screen locking, and MFA;
  • be inventoried and limited to authorized users;
  • receive vulnerability and configuration scans at least monthly; and
  • be removed from access promptly if lost, compromised, unsupported, or no longer required.

Restricted information may not be stored on personal or unmanaged devices. Remote administration must use encrypted protocols and approved access paths.

11. Secure development and change management

Coastmark changes shall be traceable from source control through production.

  • Source code must be maintained in the authorized Git repository with access limited to approved contributors.
  • Changes must be reviewed for security, tenant isolation, authorization, data handling, logging, and rollback impact in proportion to risk.
  • Automated CI must run the applicable test suite, formatting or static checks, production asset build, PostgreSQL tenant-isolation tests, and dependency vulnerability audit before release.
  • Secrets and customer data must not be committed to source control, fixtures, tickets, or build artifacts.
  • Security-sensitive integrations must fail closed when required credentials, signed webhook verification, account identity, or production preflight conditions are absent.
  • Production deployments must originate from a clean, approved Git commit, preserve durable data, create and verify a backup, retain a rollback path, and pass health and exposure checks.
  • Emergency changes require documented justification, testing as soon as practicable, and retrospective review.

12. Vulnerability management

8 West IT shall identify and remediate vulnerabilities in application dependencies, endpoints, and production assets.

  • Dependency vulnerability checks must run on every proposed release and at least monthly.
  • Employee and contractor endpoints and production assets must receive authenticated or otherwise appropriate vulnerability scans at least monthly. Public attack-surface scans must be performed at least quarterly and after material exposure changes.
  • Findings must be validated, recorded, assigned an owner, and tracked to remediation or approved exception.
  • Remediation targets are seven calendar days for Critical findings, thirty days for High findings, ninety days for Medium findings, and the next planned maintenance cycle for Low findings. Confirmed active exploitation requires immediate containment regardless of rating.
  • Patches shall be tested in proportion to operational risk and deployed sooner when credible exploitation or sensitive-data exposure increases risk.
  • Remediation shall be verified by rescanning, retesting, or documented evidence.

13. Logging, monitoring, and auditability

Security-relevant events shall be recorded and reviewed sufficiently to detect misuse, investigate incidents, and demonstrate control operation. Relevant events include authentication failures, privileged changes, access denials, payment and bank-connection lifecycle events, webhook verification failures, provider errors, deployments, backup validation, and incident actions.

Logs must not contain passwords, complete provider payloads, access tokens, session cookies, payment details, customer documents, or unnecessary personal information. Application and provider identifiers may be retained only where required for reconciliation and must be access-controlled.

Operational logs shall be retained for at least fourteen days unless a longer period is required by contract, law, investigation, or the data-retention schedule. Immutable accounting and application audit events shall be retained with the related business record. Logs associated with a security incident shall be preserved as incident evidence through closure and for at least one year afterward, unless counsel or applicable law requires longer.

The CTO or delegate shall review alerts and material security events promptly and document investigation and disposition.

14. Data retention, consent, and secure deletion

8 West IT shall obtain or rely on valid user authorization before collecting and processing consumer financial data through Plaid. Plaid Link must clearly identify the requested connection and data use. Access must be limited to the products and history needed for Coastmark banking and reconciliation functions.

Unless a different period is required by law, contract, litigation hold, or documented business need, the following schedule applies:

  • Plaid access tokens and Item identifiers: retained only while the connection is authorized and needed. On disconnect, termination, or verified deletion request, Coastmark shall request provider revocation and clear local token material after revocation succeeds or the provider confirms the Item is invalid.
  • Encrypted orphan-token revocation records: retained only until successful provider removal or a confirmed terminal invalid-Item response, then deleted.
  • Bank transactions, invoices, payments, journals, supporting receipts, consent evidence, and related audit records: seven years after the applicable fiscal year or account closure, whichever is later.
  • Temporary exports and diagnostic files containing customer information: deleted within seven days after their approved purpose is complete.
  • Routine operational logs: at least fourteen days and no longer than ninety days unless preserved for security, legal, contractual, or audit needs.
  • Rolling operational backups: fourteen days unless a different documented recovery schedule applies. Expired backups must be securely deleted through the storage lifecycle.
  • Security incident records: closure plus one year, or longer when required by counsel, insurance, contract, or law.

Verified deletion requests shall be recorded and completed within thirty days unless retention is legally or contractually required. Required records shall be restricted from ordinary use and deleted when the hold expires. Deletion must cover active application data, tokens, exports, and provider connections; backup copies may expire through the documented backup lifecycle if they remain protected and are not restored for ordinary use.

15. Third-party and service-provider security

Before a provider receives Restricted information or supports a critical service, the CTO shall review the provider's security posture, contractual protections, data use, retention, incident-notification obligations, access model, and available least-privilege configuration. Material providers must be reviewed at least annually and after a significant incident or service change.

Provider access and API credentials must use the minimum permissions required. Signed webhook verification, idempotency, replay protection, and provider account identity must be validated where supported. If a provider relationship ends, access and credentials must be revoked and retained data handled according to contract and law.

16. Incident response

Anyone who suspects a security incident must notify the CTO immediately. The CTO serves as incident commander or assigns a qualified delegate. The response process shall:

  1. Identify and assess: validate the event, determine severity, affected systems, data, tenants, providers, and legal or contractual obligations.
  2. Contain: restrict access, isolate affected assets, preserve evidence, rotate exposed credentials, and stop unauthorized processing without unnecessarily destroying evidence.
  3. Eradicate: remove malicious access or vulnerable components and address the root cause.
  4. Recover: restore from a known-good state, validate integrity, monitor for recurrence, and return services in a controlled manner.
  5. Notify: inform executive management, affected providers, customers, insurers, law enforcement, or regulators as required. If Plaid Account Information or End User Data may be affected, notify Plaid promptly at security@plaid.com.
  6. Learn: document the timeline, impact, decisions, notifications, root cause, corrective actions, owners, and due dates. Complete a post-incident review for material incidents.

Incident records must be restricted to those with a business or legal need. Public or customer statements require management approval and legal review when appropriate.

17. Business continuity, backup, and recovery

Critical Coastmark data and private customer files must be backed up on a documented schedule and before releases that may change persisted state. Backups must be access-controlled, protected to the same classification as the source, integrity-checked, and stored separately from replaceable application images.

Backup acceptance requires a successful checksum and archive-structure verification. Recovery procedures must identify the authoritative Git commit or image, database backup, private-file backup, dependencies, and validation steps. A representative restore must be tested at least quarterly and after material changes to storage or backup procedures. Failed backups or restore tests must be investigated and corrected promptly.

18. Security awareness and acceptable use

Workforce members and contractors with system access must receive security guidance at onboarding and at least annually. Training shall cover phishing, credential protection, MFA, safe data handling, incident reporting, secure development where applicable, and the prohibition on moving Restricted information to unapproved services or devices.

Users may access information only for authorized business purposes. Attempts to bypass security controls, access another tenant, share credentials, disable logging, or conceal an incident are prohibited and may result in access removal, discipline, contract termination, or legal action.

19. Control operation and evidence

The following minimum operating cadence applies after policy approval:

Activity Minimum cadence Owner Evidence
Security risk assessment and policy review Annual and after material change CTO Approved policy, risk register, review notes
Privileged and production access review Quarterly CTO Dated access inventory and dispositions
Dependency and release security checks Every release and monthly Engineering CI results, dependency audit, remediation record
Endpoint and production vulnerability scans Monthly CTO or delegate Scan report and tracked findings
Public attack-surface scan Quarterly and after exposure change CTO or delegate Scan report and remediation evidence
Backup verification Each backup or release backup Operations Checksums and archive validation
Recovery test Quarterly and after material storage change Operations Restore record and corrective actions
Material security-event review Promptly after alert CTO or delegate Investigation and disposition record
Incident response exercise Annual CTO Exercise scenario, participants, findings, actions
Critical-vendor review Annual CTO Vendor inventory and review record
Security awareness Onboarding and annual Management Completion record

The CTO shall retain evidence appropriate to the sensitivity of the control and provide it only to authorized reviewers.

20. Exceptions, enforcement, and review

Violations or suspected violations must be reported to the CTO. Access may be suspended while a suspected compromise is investigated. Confirmed violations may result in corrective action, access removal, contract termination, or legal action.

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

21. References