Enterprise trust starts with transparent controls.

StabilityLogic LLC operates on a defense-in-depth model. All applicant and landlord data is encrypted in transit (TLS 1.2+) and at rest. Production infrastructure enforces least-privilege access, audit logging, and separation of duties between operator and administrator roles.

• TLS 1.2+ for every request
• Encryption at rest for MongoDB documents and object storage
• Structured JSON audit logs for every state change (score, decision, share, export)
• Automated dependency scanning and CVE monitoring
• Role-based access with per-organization data isolation (multi-tenancy)

We collect the minimum data necessary to score, decide, and defend a rental decision — nothing more. Applicants explicitly consent before any data is collected, and can request a copy, correction, or deletion of their record at any time.

• Explicit, versioned, timestamped consent per applicant
• Applicant self-service access: view report, request correction, revoke consent
• Data minimization by default — no scraping, no third-party enrichment without disclosure
• PII redaction on shared reports and audit exports
• Full policy: see the
• Privacy Policy

HSI is a scored decision-support system — not an autonomous decision-maker. Landlords retain final approval authority. Every model release is versioned, documented in a model card, and reviewed for disparate-impact risk before deployment.

• Versioned model releases with reproducible input hashes
• Explainability panel on every decision — no black-box outputs
• Human-in-the-loop landlord review required before adverse action
• Bias-monitoring pipeline on approval, decline, and conditional rates by protected class proxies
• No use of protected-class variables (race, religion, national origin, familial status) as scoring inputs

StabilityLogic LLC affirms full compliance with the Fair Housing Act, the Equal Credit Opportunity Act (ECOA), and applicable state and local fair-housing statutes. Housing type is never a penalty in the HSI model — hotel residents, subsidized-housing residents, and family-placed applicants are scored on the same behavior-first criteria as apartment tenants.

• No protected-class inputs (race, religion, sex, familial status, national origin, disability)
• Adverse-action reports use FCRA-style language and identify the top decision factors
• Recovery Applicant Framework rewards rebound after documented hardship
• Fair-housing external audit scheduled Q4 2026

Applicant data is treated as sensitive by default. We retain scored records for the minimum period needed to defend a rental decision under FCRA and state statute, then hard-delete on schedule. Landlords cannot export un-consented applicant records.

• Retention: applicant records kept for statute-of-limitations window, then hard-deleted
• No sale of applicant data — ever
• Sub-processors listed in the Privacy Policy; SLAs enforced
• Data-processing addenda available for enterprise pilots
• Data residency: U.S. primary regions (multi-AZ)

Component-level status, recent-incident log, and P1/P2/P3 response expectations are published on our system-status page. Enterprise pilot partners additionally receive direct email notification on any incident above severity-3.

Two documents commonly requested by enterprise security, procurement, and legal teams — available for direct download without a form. Both are non-confidential and safe to share internally with your risk and legal reviewers.

Deeper questionnaires (SIG, CAIQ, or a custom vendor-risk template) are answered on request under NDA. The current authoritative sub-processors register lives at /subprocessors.

Every enterprise contract includes a Service Level Agreement executed alongside the Master Services Agreement and Data Processing Agreement. The commitments below are the enterprise-tier defaults; specific numbers are negotiated per deployment.

The signed SLA schedule takes precedence over these summary figures. Numbers here reflect the current enterprise-tier default and are not a public commitment absent an executed agreement.

Enterprise support is delivered by named engineers assigned during onboarding. The hours below define the default coverage window; extended coverage tiers (12x5 and 24x7) are available as a Professional Services add-on.

Outside standard hours, monitoring and paging continue automatically for production incidents. The public system-status page reflects real-time posture at /status.

StabilityLogic LLC operates a documented Incident Response Plan (IRP) with defined severity levels, response timelines, and customer-communication commitments. The IRP is reviewed at least annually and after every material incident.

• A named Incident Commander is designated for every P1 event and remains on the bridge until resolution.
• Confirmed security incidents involving personal data trigger written customer notice within 72 hours, consistent with GDPR Article 33 and equivalent state statutes.
• Every P1 and P2 incident receives a written post-incident review with root cause, timeline, remediation, and prevention actions — shared with impacted customers.
• The system-status page publishes component-level state changes for the current and prior 14-day window.

The Business Continuity Plan (BCP) covers operational resilience across staffing, vendors, and infrastructure. It is designed to keep enterprise customers scoring and deciding through common disruption scenarios — regional cloud events, key-person absence, or third-party vendor failure.

• Multi-AZ deployment across at least two U.S. availability zones for the primary production database and application tier.
• Documented runbooks for each critical workflow: applicant intake, HSI scoring, decision issuance, and adverse-action report delivery.
• Cross-trained on-call rotation — no single-person dependency on any production-critical path.
• Contractual continuity: at least one operationally-equivalent backup path is identified for every subprocessor category (compute, database, email, SMS, banking, LLM).
• BCP tabletop exercise scheduled annually with documented findings and remediation items.
• Vendor-failure playbooks maintained for each subprocessor listed on the /subprocessors register.

BCP artifacts (runbooks, tabletop findings, and vendor-failure playbooks) are shared with enterprise customers under NDA on request.

The Disaster Recovery (DR) program addresses catastrophic loss of the primary environment. Recovery objectives are engineered against the enterprise-tier defaults below and are validated in scheduled restore exercises.

• Backups are encrypted at rest and in transit; access is restricted and logged.
• Restore exercises are performed at least twice per year and after any material infrastructure change; results feed the BCP tabletop.
• Audit-trail integrity is validated on every restore — hash-linked events must reconcile end-to-end before service is returned to production.
• In the event of a declared disaster, customer communications follow the P1 incident cadence above.

Direct addresses for security, privacy, and compliance correspondence. All addresses are monitored during standard business hours; time-sensitive security matters should also be paged via the responsible-disclosure channel below.

Physical mail: 2108 N St, Ste N, Sacramento, CA 95816, USA.

StabilityLogic LLC welcomes coordinated disclosure from independent security researchers. If you believe you have identified a vulnerability affecting the StabilityLogic platform, please report it to security@stabilitylogic.com. We commit to the timelines and safe-harbor terms below.

• Acknowledgement of receipt within 3 business days.
• Initial triage severity and expected remediation window communicated within 10 business days.
• Coordinated disclosure timeline — public disclosure requires 90 days from initial report or joint agreement, whichever comes first.
• Safe harbor: good-faith research consistent with this policy will not be pursued through legal action, and we will work with you on public credit if you wish.
• Out of scope: physical attacks, social engineering, denial-of-service testing, and testing against third-party subprocessors.

A public bug-bounty program is a planned enhancement; timing is captured in the Compliance Roadmap below. This is not a certified program today and no monetary reward is guaranteed absent a signed program agreement.

We publish our subprocessor register and answer standard vendor-risk questionnaires so procurement and third-party-risk teams can complete their reviews without a private disclosure request.

• Authoritative subprocessors register lives at /subprocessors — Company · Purpose · Jurisdiction · Data category for every vendor that processes data on our behalf.
• Standard questionnaires answered on request under NDA: SIG (Standardized Information Gathering), CAIQ v4 (Consensus Assessment Initiative Questionnaire), and custom vendor-risk templates.
• Every subprocessor is contractually bound by a Data Processing Addendum equivalent to or stronger than our customer-facing DPA.
• Enterprise customers receive at least 30 days written notice before any material change to the subprocessor register, with an objection window per the executed DPA.
• Subprocessor onboarding requires a documented risk review covering data category, jurisdiction, security controls, and business-criticality.

We publish the planned audit calendar so enterprise buyers can align their own procurement and vendor-review cycles. Every item below is a scheduled or planned engagement — not a completed attestation. Nothing on this page should be read as a claim of certification not yet earned.

Completed attestations, when they exist, will be listed here with the issuing firm, report window, and a redacted copy available to enterprise customers under NDA. No such attestation is currently in force.

Enterprise buyers want to know where we're headed on compliance — here it is, plainly.