Information security policy

1. Purpose

This Information Security Policy (“the Policy”) sets out how Kenilworth Townhome HOA, Inc. (“the HOA”) protects the data its residents entrust to the residents-only portal at kenilworth-hoa.com. The Policy is the umbrella document for all of the HOA’s security commitments, including those required by third-party financial-data providers (Plaid, Stripe) for continued data access.

2. Scope

The Policy applies to:

• All software, infrastructure, and operational processes that support the residents portal at kenilworth-hoa.com.
• Personal and financial data of unit owners, current tenants recorded by an owner, and HOA officers acting in their administrative capacity.
• Third-party service providers used to operate the portal (listed in §11).

The Policy does not cover the HOA’s offline records (paper meeting minutes, vendor contracts, insurance documents) which are governed by the HOA’s bylaws and corporate records-retention practices.

3. Roles and responsibilities

The HOA is a self-managed 6-unit association. Three officers carry administrative responsibility:

• President — overall accountability for the Policy. Reviews and approves changes. Approves admin-account provisioning and de-provisioning.
• Treasurer — operational ownership of payment-related systems (Stripe, Plaid). Approves changes to billing data and reconciliation processes.
• Secretary — records access reviews and maintains the audit trail of approvals.

The President is the sole accountable signer of attestations made to third-party providers on the HOA’s behalf.

4. Information security principles

The HOA commits to:

1. Collecting only the data needed to operate the residents portal (least-data principle).
2. Encrypting sensitive data at rest and in transit.
3. Restricting administrative access to current officers and removing it promptly when an officer’s role ends.
4. Patching identified software vulnerabilities within defined timeframes (§7).
5. Monitoring its software stack for end-of-life status (§8) and upgrading in advance of EOL.
6. Reviewing access privileges and the inventory of linked third-party services on a periodic cadence (§9).
7. Communicating material data-handling changes to residents through the channels in the Privacy policy.

5. Access control

5.1 Authentication

• All portal accounts authenticate with email + password. Passwords are hashed with bcrypt before storage; the plaintext password is never persisted.
• Two-factor authentication (TOTP) is available for all accounts and required for any officer holding administrative privileges. TOTP secrets are encrypted at rest using AES-256-GCM with a key derived from the application authentication secret.
• Session cookies are HTTP-only, secure, and signed. Session tokens carry a maximum 30-day validity, with a per-request database lookup that revokes the session immediately if the underlying account is deactivated.

5.2 Authorization

• The portal recognizes two roles: administrator (HOA officers) and resident (unit owners).
• All administrative routes are gated server-side with a requireAdmin() check that runs before any data is rendered or mutated. Client-side hiding of admin UI is treated as cosmetic only — server-side enforcement is the sole authority.
• Resident-scoped queries are constrained at the data layer: a resident may only view records (charges, payments, documents) tied to a unit they currently own (via an active ownership tenure).

5.3 Account provisioning

Account creation is admin-provisioned only. There is no public sign-up. New accounts are issued with a single-use invite token, expire if unused, and require the recipient to set their own password before first sign-in.

6. De-provisioning of access

When an HOA officer’s term ends, when an owner sells their unit, or when an account otherwise no longer requires access:

1. An administrator marks the user as soft-deleted in the portal.
2. Soft-deletion sets a deleted_at timestamp on the user record. The per-request session validation described in §5.1 detects the deletion and refuses to issue or refresh sessions for that account on the next request — typical effective revocation time is under 60 seconds of administrator action, capped at the JWT lifetime (30 days) only if the user happens not to make any request in between.
3. Soft-deleted user records remain in the database for tenure auditability (charges, payments, and document uploads tied to the closed tenure stay attached to it).
4. Hard deletion of the personal-profile fields (name, email, optional phone, optional profile image) can be requested by the user or initiated by an administrator under the Data Retention policy.

This procedure constitutes the HOA’s automated de-provisioning of access.

7. Vulnerability management and patching

7.1 Identification

The HOA’s source repository is configured with GitHub Dependabot for both software-composition vulnerability alerts and automated security fix pull requests. Alerts cover the npm dependency tree and the GitHub Actions used in CI workflows. The HOA also subscribes to security advisories from each of its primary platform providers (Vercel, Neon, Sentry).

7.2 Classification

Vulnerabilities are classified by their CVSS v3 base score, as published in the Dependabot or upstream advisory: Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9).

7.3 Patching service-level agreements

The HOA commits to remediating identified vulnerabilities within the following timeframes from the date the alert is received:

• Critical — 72 hours
• High — 14 days
• Medium — 30 days
• Low — 90 days

“Remediation” means applying the upstream fix, applying a documented mitigation, or accepting the risk in writing with the President’s approval. Risk acceptance is reviewed at each periodic access review (§9).

8. End-of-life software monitoring

The HOA commits to monitoring the end-of-life status of its primary stack components and upgrading in advance of the EOL date. The primary stack as of the effective date: Node.js 22 LTS (upgrade to next LTS within 6 months of handover), Next.js 16 (upgrade to next major within 6 months of release), pnpm 10 (track current major), Postgres via Neon (track Neon’s supported versions), Vercel platform runtime (track Vercel’s supported runtimes). Dependabot version updates run weekly; platform components are tracked through provider EOL announcements.

9. Periodic access review

The HOA conducts an access review on a quarterly cadence. Each review covers:

1. The list of administrator and resident accounts active in the portal, and confirmation that each still corresponds to a current officer or current owner.
2. The list of linked third-party Items (Plaid bank links, Stripe customers, Google Drive service accounts) and confirmation that each is still required.
3. The status of any open vulnerability alerts and their position relative to the SLAs in §7.
4. Any changes to processor list or data flows that would warrant a Privacy policy update.

The Secretary records the date of each review, who participated, and any actions taken.

10. Data encryption

In transit: all traffic to and from kenilworth-hoa.com is served over TLS, terminated at the Vercel edge. Connections to all third-party APIs are TLS-only.

At rest:passwords are hashed with bcrypt; two-factor secrets are encrypted with AES-256-GCM (key derived from the application authentication secret via SHA-256); Plaid access tokens are encrypted with AES-256-GCM under a domain-separated key (derived from a “plaid:” prefix concatenated with the authentication secret) so a leak of one cannot decrypt the other; database storage is encrypted at rest by Neon; document storage is encrypted at rest by Google Drive under the HOA’s Workspace.

11. Third-party service providers

Each processor below is governed by its own data-processing terms. The roster is reviewed at each periodic access review (§9): Vercel (hosting, edge TLS, request logs); Neon (Postgres); Stripe (ACH payments); Plaid (read-only sync of the HOA’s own bank account — residents’ banks are not linked through Plaid); Google Drive + Workspace (documents, HOA email); Resend (transactional email); Sentry (error monitoring, with personal-information scrubbing); GitHub (source-code repository, CI/CD).

12. Incident response

Application errors are reported in real time to Sentry with personal information scrubbed; only an internal user identifier is attached. Provider-level incidents surface through each provider’s status page. When a security incident is identified the President is notified immediately; if resident data or authentication is exposed, residents are notified by email within a reasonable time generally not to exceed 72 hours of confirmed impact; the Secretary records the incident, its impact, and the corrective actions taken.

13. Data retention

Retention windows, disposal triggers, and procedures are documented in the Data Retention and Disposal Policy.

14. Acceptable use

User-facing acceptable-use rules are documented in the Terms of Service.

15. Privacy

Privacy practices are documented in the Privacy Policy.

16. Policy review and approval

This Policy is reviewed at least annually and whenever a material change in systems, processors, or applicable regulations warrants an update. Version history, and the President’s signature line, appear in the downloadable .docx.

Appendix A — Plaid attestation coverage

The HOA’s Plaid Production data-access requires attestation to six security practices in the Plaid Compliance Center → Data Security tab. Each is supported by a section of this Policy: §6 covers automated de-provisioning; §5 covers the access control policy; §7 covers vulnerability patching SLAs; §8 covers end-of-life software monitoring; this document in its entirety is the Information Security Policy itself; §9 covers periodic access reviews and audits.

Contact

Kenilworth Townhome HOA, Inc.
1401 Kenilworth Ave, Charlotte NC 28203
hoa@kenilworth-hoa.com