Information Security Program

EverLucent Vault LLC ("Company") has established this Information Security Program ("Program") to protect the confidentiality, integrity, and availability of information assets and to support the trust placed in us by our users. This document serves as the system-level charter for security governance and references all supporting controls, policies, and procedures.

1. Purpose and scope

This Program defines the security governance framework for EverLucent Vault, a software platform that provides compliance tracking, clinical decision support, and business operations tooling for nurse practitioners and similar licensed professionals.

The scope covers all systems, networks, applications, data stores, vendor relationships, and personnel involved in the development, operation, and support of the Service. This Program applies to the founder, any future employees, contractors, and third-party service providers with access to Company systems or data.

2. Roles and responsibilities

• Founder / Security Officer — Authorizes this Program, owns risk acceptance decisions, reviews security incidents, and approves material changes to security architecture or vendor relationships.
• Engineering — Implements secure software development practices, maintains access controls, encryption, logging, and patching cadence.
• Users — Responsible for maintaining strong credentials, using MFA where available, reporting suspicious activity, and ensuring that patient identifiers or other protected information are not entered into the Service.

3. Risk assessment

The Company conducts risk assessments on an ongoing basis and formally reviews them at least annually. Risk assessment activities include:

• Identifying information assets and data flows (user account data, compliance records, audit logs).
• Evaluating threats (unauthorized access, data leakage, service disruption, vendor failure).
• Assessing vulnerabilities (misconfiguration, software flaws, credential compromise, social engineering).
• Scoring risk based on likelihood and impact, then prioritizing mitigations.

Risk treatment options include mitigation (technical or procedural controls), transference (vendor contracts, insurance), or acceptance (documented with business justification for residual risks within tolerance).

4. Access control policy

This section is the Company's defined and documented access control policy. It governs how access to Company systems, data stores, third-party consoles, and financial-data integrations is granted, modified, reviewed, and revoked. It is reviewed at least annually and whenever roles, vendors, or architecture materially change.

• Zero-trust application access architecture. The Service treats no user, device, or request as trusted by default. Access is not granted based on network location or client-side assertions; every request is authenticated and revalidated server-side, and authorization is enforced at the database layer through Row Level Security so no application code path can bypass it. Service-role credentials are server-side only, sessions are short-lived and invalidated on sign-out, and MFA is required before connecting financial-data integrations. This identity-first, least-privilege design minimizes implicit trust and limits blast radius. Because the Company operates a cloud SaaS product rather than a corporate network, device-trust agents and network micro-segmentation are outside product scope; the zero-trust model applies to the application, data, and authentication layers.
• Least privilege. Every identity receives the minimum access required for its function, and nothing more. Users can access only their own records. Database access is enforced through Row Level Security (RLS) at the data layer, so authorization is applied by the database itself rather than by application code alone.
• Role-based access control. Access is assigned by role, not by individual exception. Application roles are stored in a dedicated roles table separate from user profiles and evaluated server-side; roles are never inferred from browser storage or client-supplied values. Defined roles are: user (own records only),admin (platform administration and content review surfaces), andservice (server-side automation, no interactive sign-in). Privileged service-role credentials are used only in server-side code paths and are never exposed to the browser.
• Granting access. Interactive accounts are created only through the Service's authenticated sign-up flow; anonymous sign-up is disabled. Elevated roles are granted only by the Security Officer, only for a documented business need, and only after the requester's identity is confirmed. Vendor console access (infrastructure, payments, financial data) is granted individually — never through shared logins.
• Modifying access. Role changes are made by the Security Officer through the roles table or the relevant vendor console and take effect on the next authorization check. Access changes are logged with actor, timestamp, and the role affected.
• De-provisioning and offboarding. When an employee, contractor, or other workforce member terminates, transfers, or otherwise changes role, access is revoked or adjusted the same day. The offboarding workflow is initiated by the Security Officer (or, when an HR system is in place, by an HR-driven ticket delivered to the Security Officer) and includes: disabling the identity in the authentication provider, deleting role assignments, invalidating all active sessions and tokens, removing the identity from vendor and cloud console memberships, and rotating any secrets or API keys the identity could have accessed. Transferred users receive only the permissions required by their new role after their old permissions are removed. Each offboarding action is logged with actor, timestamp, and scope.
• Revoking access. Access is revoked promptly on role change, contract end, separation, or suspected compromise — targeted within one business day, and immediately where compromise is suspected. Revocation includes deleting the role assignment, invalidating active sessions, removing vendor console membership, and rotating any secret the identity could have held. Financial-institution connections are revoked by disconnecting the item with the provider and deleting stored access tokens.
• Periodic access reviews and audits. At least quarterly, the Security Officer performs an access review to verify that all access rights remain appropriate and compliant with this access control policy. The review covers all human accounts with elevated roles, all vendor and cloud console memberships, and all active API keys and secrets. Excessive, outdated, or unused permissions are identified and removed, and the review outcome (date, scope, reviewer, and any remediation) is recorded and retained for at least three years.
• Authentication. Password-based sign-in requires a minimum-complexity password and is checked against known-breached-password lists. Users may also sign in with Google, which enforces Google's own account protections (including 2-Step Verification when enabled on the Google account).
• Multi-factor authentication (MFA). The Service supports time-based one-time password (TOTP) authenticators (e.g., Google Authenticator, Authy, 1Password) for every account, along with single-use recovery codes issued at enrollment. MFA is available to all users, strongly recommended for any account handling clinical or financial data, and required before a user may connect a financial-data integration (such as Plaid) where present. Users authenticating with Google may rely on Google 2-Step Verification in lieu of app-level MFA, except where MFA is required by the preceding sentence.
• Session management. Sessions are bound to tokens with finite lifetimes and are revalidated server-side on every privileged request. Inactive sessions expire automatically, and sign-out clears cached application data.
• Administrative access and internal systems MFA. All administrative access to systems that store or process consumer data is limited to the founder, secured with strong unique credentials, and protected with MFA. Covered systems include the cloud infrastructure/database console (Lovable Cloud / Supabase), edge/security platform (Cloudflare), payment/merchant processors (Paddle, Stripe Connect), financial-data integration console (Plaid), domain/email provider, source-control and deployment platform, and the password manager. MFA is implemented through time-based one-time passwords (TOTP) via an authenticator app, push-based authenticator approval, or platform biometric verification (e.g., Windows Hello, Apple Touch ID / Face ID) where available; SMS-based MFA is avoided wherever a stronger method is offered. Administrative credentials are never shared, never reused across services, and stored only in the password manager. Administrative actions are logged.
• Credential and secret handling. Secrets are stored in the managed secret store of the hosting platform, injected into server-side runtime only, and never committed to source control or shipped to the browser. Financial-integration access tokens are stored encrypted and readable only by server-side code.

5. Data protection

• Encryption in transit. TLS 1.2 or higher protects all data transmitted between users and the Service.
• Encryption at rest. Database storage and object storage use AES-256 or equivalent encryption provided by the cloud infrastructure vendor.
• Data classification. The Service is designed to store professional compliance and business data, not Protected Health Information (PHI). Users are instructed not to enter PHI, and inputs carry de-identification reminders.
• Retention and deletion. Data is retained for the life of the subscription plus a reasonable period to meet legal and tax obligations. Users may request deletion by emailing privacy@everlucentvault.com. Deletion is completed within 30 days. Encrypted backups expire automatically within 7 days.

6. Vendor and supply-chain management

The Company evaluates vendors before engagement and monitors them throughout the relationship. Current subprocessors are listed on our Subprocessors page.

• Cloud infrastructure (Lovable Cloud / Supabase) — Provides managed database, authentication, storage, and RLS. Reviewed for SOC 2 Type II coverage and encryption practices.
• Edge compute and CDN (Cloudflare) — Provides runtime, DDoS protection, and edge caching. Reviewed for security and availability commitments.
• Merchant of Record (Paddle) — Handles billing, tax, and payment data. The Company does not store full payment card numbers.
• AI providers (Google, OpenAI) — Process de-identified text for clinical summaries and interpretation. Inputs are not used to train models per provider terms.

Vendor contracts include confidentiality and security obligations. Vendor access to Company data is limited to what is necessary to perform their function.

7. Vulnerability management and patch management

The Company maintains a vulnerability management program to detect and remediate security weaknesses in software dependencies, production infrastructure, and endpoint devices used to access Company systems.

• Application dependency scanning. The source code repository is configured with automated dependency scanning to identify known vulnerabilities in third-party libraries (for example, npm audit and Dependabot-style alerts). Critical and high-severity findings are triaged and remediated on a risk-prioritized basis; the Engineering function tracks open findings to resolution.
• Infrastructure and production asset scanning. Production infrastructure is hosted on managed cloud platforms (Lovable Cloud / Supabase, Cloudflare) that perform their own vulnerability scanning, patching, and security monitoring of the underlying operating systems, hypervisors, network edge, and managed services. The Company reviews provider security attestations and incident notifications as part of vendor management.
• Endpoint device scanning. Devices used to access Company systems and data (founder-owned or company-assigned laptops, workstations, and mobile devices) are configured to apply security patches and operating-system updates automatically, and run modern anti-malware or endpoint detection and response (EDR) software where available. As the workforce grows, the Company will implement a centralized endpoint vulnerability scanning and EDR solution with a documented patch SLA.
• Patch management cadence. Critical and high-severity vulnerabilities are patched as soon as practical, typically within seven days of a fix becoming available. Lower-severity patches are applied during regular maintenance windows or at least monthly. Security patches for vendor-managed infrastructure are applied by the vendor according to their published schedules.
• Scan results and remediation tracking. Vulnerability scan results are reviewed when generated, and remediation actions are tracked to completion. Findings that cannot be remediated immediately are documented with a risk-acceptance rationale and compensating controls.

8. Secure development and operations

• Change management. Production changes are made through tracked source control with peer review where feasible. Infrastructure changes are versioned and auditable.
• Dependency management. Dependencies are scanned for known vulnerabilities. Critical and high-severity findings are patched on a risk-prioritized basis.
• Monitoring and logging. Application and infrastructure logs are collected centrally. Anomaly patterns that may indicate intrusion or abuse trigger alerts.
• Audit logging. User actions that create, modify, or delete stored artifacts are recorded in an append-only audit log visible to the account owner.

9. Incident response

The Company maintains an incident response capability with the following stages:

• Detection. Automated monitoring, user reports, and vendor security notifications.
• Analysis and containment. Upon detection, the founder assesses scope, contains the incident to prevent further impact, and preserves evidence.
• Eradication and recovery. Root cause is addressed, affected systems are restored, and verification testing is performed before returning to normal operations.
• Notification. If a security incident compromises the confidentiality, integrity, or availability of user personal information, affected users are notified by email without undue delay and no later than 72 hours after confirmation. Regulators and other parties are notified where required by law.
• Post-incident review. A retrospective is conducted to identify preventive improvements and update this Program where needed.

10. Security awareness

As a sole-founder operation, security awareness is embedded in daily operations. The founder stays current on relevant threats, tooling updates, and vendor security advisories. As the team grows, formal security awareness training will be provided at onboarding and refreshed annually, covering phishing recognition, password hygiene, safe handling of user data, and incident reporting.

11. Business continuity

• Backups. Automated point-in-time database backups are retained for 7 days.
• Recovery testing. Backup restoration procedures are tested periodically to validate recovery time objectives.
• Redundancy. Critical infrastructure is deployed on managed platforms with vendor-provided availability and failover capabilities.

12. Compliance and legal

• The Service is designed for U.S. licensed healthcare professionals and is not marketed to or intended for use by EU/UK residents.
• The Company is not a HIPAA-covered entity and does not offer a Business Associate Agreement. Users must not enter PHI into the Service.
• The Company maintains a Privacy Notice and Terms of Service that describe data handling practices, user rights, and breach-notification commitments.

13. Policy review and maintenance schedule

This Program is reviewed at least annually and after any significant security incident, organizational change, or material vendor change. Updates are versioned and communicated to users via the Service or email for material changes. The current version is always available at this URL.

The following review calendar keeps the Company ahead of audit, vendor attestation, and regulatory deadlines. Reviews are recorded with the date, reviewer, and any action taken.

Trigger-based review: Any of the following events require a review of the relevant controls within five business days: data breach or security incident, termination or transfer of any workforce member, addition of a new financial or clinical data integration, change in organizational structure, or receipt of a regulator or vendor security notice.

Record keeping: Each review is documented with the date, the reviewer, the scope reviewed, and any remediation assigned. Records are retained for at least three years.

Next scheduled annual review: Within 12 months of the effective date listed at the top of this page.

14. Contact

Security questions, incident reports, or Program inquiries may be sent to security@everlucentvault.com.