Information Security Policy

HAMRR — Iway Development — Version 1.0 — Effective March 23, 2026
Security Contact: Matt, Administrator — matt@iwaycorp.com

1. Purpose

This policy establishes the information security requirements for HAMRR ("the Service"), a real estate development and property management SaaS platform operated by Iway Development. It defines controls to protect the confidentiality, integrity, and availability of customer data, including financial data received from third-party integrations such as Plaid.

2. Scope

This policy applies to all production systems, data stores, APIs, serverless functions, and administrative access associated with HAMRR. This includes application infrastructure (Vercel, Supabase), third-party integrations (Plaid, Stripe, WorkOS, Anthropic), and all personnel with access to production systems.

3. Governance and Risk Management

3.1 Security Responsibility

The designated security contact is responsible for: maintaining this policy; monitoring security events; coordinating incident response; conducting periodic access reviews; and managing vulnerability remediation.

3.2 Risk Assessment

Risk assessments are conducted quarterly and upon material changes to infrastructure, integrations, or data handling practices. Assessments evaluate threats to consumer financial data, authentication systems, and data storage.

3.3 Policy Review

This policy is reviewed and updated at minimum annually, or upon: material infrastructure changes; new third-party integrations handling financial data; security incidents; or changes to regulatory requirements.

4. Identity and Access Management

4.1 Consumer Authentication

ControlImplementation
Password hashingbcrypt with 12 rounds, auto-migration from legacy
Multi-factor authenticationTOTP-based 2FA with backup codes. Required before accessing Plaid bank linking.
Session managementJWT with 24-hour expiry, 5-minute validation polling, 3-strike logout
Brute force protection10 login attempts per 15 minutes per IP, Cloudflare Turnstile CAPTCHA
Midnight session expiryAll sessions terminate at midnight for security hygiene

4.2 Administrative Access

SystemControl
Vercel (hosting)MFA-protected account, SSO where available
Supabase (database)MFA-protected account, role-based RLS policies
GitHub (source code)MFA-protected account, branch protections on main
Plaid DashboardMFA-protected account
Stripe DashboardMFA-protected account

4.3 Role-Based Access Control

The application enforces role-based access at both the API and UI level. Roles: Superadmin, Admin, Manager, Editor, Viewer. Tenant isolation is enforced via JWT claims — each tenant's data key is resolved from the JWT, preventing cross-tenant access at the API layer.

4.4 Access Reviews

Access reviews are conducted quarterly via the built-in Audit Log (Settings → Audit Log). Reviews verify active users, role assignments, and last activity timestamps. Inactive accounts are deactivated after 90 days.

5. Infrastructure and Network Security

5.1 Encryption in Transit

All client-server communication uses TLS 1.2 or higher, enforced by Vercel's edge network and Cloudflare. API endpoints reject non-HTTPS connections. Supabase connections use TLS-encrypted PostgreSQL.

5.2 Encryption at Rest

Data TypeEncryption
Plaid access tokensAES-256-CBC with per-deployment encryption key
API keys (Anthropic, etc.)AES-256-CBC with per-deployment encryption key
Database (Supabase)AWS-managed encryption at rest (AES-256)
Passwordsbcrypt (12 rounds) — not reversible
Consumer bank account numbersNot stored. Only last 4 digits retained for display.

5.3 CORS and API Security

All API endpoints enforce CORS restricted to the production domain (hamrr.com). No wildcard origins. JWT required on every endpoint except CAPTCHA verification and Stripe webhooks (which use Stripe signature verification).

5.4 Rate Limiting

EndpointLimit
Login10 / 15 minutes
Signup5 / hour
Data save120 / hour
AI chat60 / hour
Plaid operations60 / hour
Data deletion10 / hour

6. Development and Vulnerability Management

6.1 Secure Development

All code changes are committed to a version-controlled repository (GitHub). Dependencies are audited via npm audit before each deployment. Known vulnerabilities are patched within the following SLAs:

SeverityPatch SLA
Critical24 hours
High7 days
Medium30 days
LowNext release cycle

6.2 Vulnerability Scanning

Automated dependency scanning (npm audit) is performed before each deployment. Production assets (serverless functions on Vercel) are patched via dependency updates. Infrastructure vulnerabilities are managed by platform providers (Vercel, Supabase, Cloudflare).

7. Data Handling and Retention

7.1 Data Classification

ClassificationExamplesControls
Highly SensitivePlaid access tokens, encryption keys, passwordsEncrypted at rest, never logged, never exposed to client
SensitiveBank transactions, balances, account numbers, tenant PIIEncrypted at rest, access-controlled, audit-logged
InternalProject data, milestones, budgetsTenant-isolated, access-controlled

7.2 Retention Policy

Data TypeRetention PeriodDeletion Method
Bank transactions2 yearsAutomated purge via retention endpoint
Audit logs7 yearsAutomated purge
Plaid access tokensUntil disconnectImmediate deletion on disconnect + Plaid item removal
Deleted user accounts30-day grace periodFull purge after grace period
Active account dataDuration of accountFull deletion on account closure

7.3 Data Deletion

Users may request deletion of: their financial data (bank connections, transactions); or their entire account. Financial data deletion immediately disconnects Plaid items and purges stored tokens and transactions. Account deletion enters a 30-day grace period before full purge. All deletion actions are audit-logged.

7.4 Data Portability

Users may export their data at any time via Settings → Export (CSV/JSON) or via the data export API. Exports include project data, contact data, and financial summaries (transaction detail excluded from bulk export for security).

8. Third-Party Risk Management

8.1 Plaid

Plaid access tokens are encrypted at rest (AES-256-CBC). Consumer bank credentials are never transmitted to or stored by HAMRR — authentication occurs entirely within Plaid's secure Link widget. Transaction data is synced via Plaid's incremental sync API and subject to the retention policy above.

8.2 Stripe

Payment processing is delegated to Stripe. HAMRR does not store, process, or transmit credit card numbers. Webhook integrity is verified via Stripe signature verification.

8.3 Supabase

Data is stored in Supabase's managed PostgreSQL on AWS infrastructure, with encryption at rest and in transit. Row-level security policies enforce tenant isolation.

9. Incident Response

9.1 Detection

Security events are detected via: the built-in audit trail (dual-write to Supabase + API); error boundary crash logging; rate limit triggers; and failed authentication monitoring.

9.2 Response Procedure

Upon detection of a security incident: (1) Contain — revoke compromised tokens, rotate secrets; (2) Assess — determine scope of data affected; (3) Notify — inform affected users within 72 hours; (4) Remediate — patch vulnerability, deploy fix; (5) Review — conduct post-incident review and update this policy if needed.

9.3 Breach Notification

In the event of a data breach involving consumer financial data, affected consumers and Plaid will be notified within 72 hours. Notification will include: nature of the breach; data types affected; remediation steps taken; and consumer protective measures.

10. Compliance

This policy supports compliance with: Plaid's security requirements for production API access; applicable state and federal data privacy laws (CCPA, state breach notification laws); and PCI DSS requirements (delegated to Stripe for payment processing).


Document Version 1.0 — March 2026 — Next Review: June 2026