Section 1
Built on private-by-default infrastructure
- Every database table enforces row-level security at the database tier, not just in application code. Even a bug in a server action cannot return a row the requester isn't authorized to see.
- Uploaded documents live in a private storage bucket. They are served exclusively via short-lived signed URLs (5-minute expiry) minted server-side after an authorization check.
- Applicants see their documents in a no-download in-browser viewer. The assembled package PDF can only be downloaded by the people the package has been shared with — the agent or property manager who owns it, the reviewers they have shared it with, and platform administrators — and every download is recorded in our audit log with the downloader's email and timestamp.
- Access to a package is per person and per package: a reviewer sees an application only when they own it or it has been shared with them, at a level the owner chooses (view or edit) and can revoke at any time. Being on a building's team never opens a package by itself.
- Data is encrypted in transit (TLS 1.2+ with HSTS) and at rest (AES-256, managed by Supabase).
Section 2
Automated SSN and account-number redaction
Every uploaded document is read on the way in by an automated pipeline — the file's own text layer for digital pages, Google Document AI OCR for scans — and rewritten before it becomes visible to anyone other than the original uploader. Social Security numbers and bank account numbers are detected, and every page that carries one is re-rendered as an image with the text beneath the redaction removed from the file — not merely covered — so it cannot be recovered by copying, searching or extracting text from the document or the assembled package. The pre-redaction copy is kept on a storage path that no user account can read, for the reviewer-side tools that need the original geometry, and is deleted with the document under the retention rules in section 8.
SSNs and account numbers shown in the user interface are masked to the last four digits as a defense-in-depth secondary control.
Section 3
Authentication and multi-factor authentication
- Identity is managed by Supabase Auth. Passwords must be at least 10 characters with mixed case and a digit.
- Sessions use HTTP-only, secure cookies. Every new session is recorded in the audit log with IP and user-agent.
- Two-factor authentication (SMS one-time passcode via Twilio Verify) is available to all users from Profile → Two-Factor Authentication and is optional.
- Administrative access to upstream providers (Supabase, Vercel, GitHub, Stripe, Google Cloud) requires multi-factor authentication on every account.
Section 4
Audit logging
Sensitive actions — every session start, every document view, every package download, every page edit, every billing event — are written to an append-only audit log, readable only by platform administrators and never updated or deleted, with the actor, IP, user-agent, and structured metadata. Audit-log writes are designed to fail silently in the rare event the log is unreachable; they never block the underlying user action, but the action proceeds without a log entry only after the write fails.
Section 5
Rate limiting
Authentication endpoints, mutation server actions, and signed-URL document access are rate-limited per user and per IP. Limits are enforced across our entire serverless fleet via a shared Upstash Redis backend, so a malicious caller cannot evade the limit by rotating Vercel instances.
Section 6
Payment data
AppWiz does not store credit card numbers. Subscription and credit-pack payments are handled entirely by Stripe, a PCI DSS Level 1-certified processor. Card data never touches our servers.
Section 7
AI processing
We use Google Gemini and Document AI on Google's paid tier to extract structured fields from uploaded documents and to generate executive summaries for board reviewers. Per Google's paid-tier terms, prompts and attachments are not used to train Google's models. TypeSafe AI checks whether an uploaded file looks like the document that was requested; it receives only the text of the first pages, with Social Security numbers and account numbers masked before it is sent, and never the file name. Anthropic's Claude is used solely as an assistive engineering tool and is not in AppWiz's production data path.
Section 8
Document retention
- Application documents are automatically deleted 30 days after a final decision (approval, denial, or withdrawal) on the application.
- An application that no one opens or changes for 30 days is permanently deleted with its documents, after its agent and applicants are notified 7 days beforehand. Any view or edit resets the clock.
- Account data is retained until the user requests deletion via their profile page.
Section 9
Incident response
AppWiz maintains a written incident response procedure covering detection, containment, eradication, recovery, and notification. For any incident involving unauthorized access to private personal information, we notify affected users and applicable regulators within 72 hours of confirmed breach, consistent with the New York SHIELD Act and analogous state laws.
Section 10
Sub-processors
AppWiz uses the following sub-processors. Each is selected for a specific function and reviewed annually:
- SupabaseDatabase, authentication, storageSOC 2 Type II
- VercelApplication hostingSOC 2 Type II
- StripePayment processingPCI DSS Level 1
- TwilioSMS one-time passcode delivery for two-factor authenticationSOC 2 Type II, ISO 27001
- ResendTransactional emailSOC 2 Type II
- Google CloudGemini API, Document AI, Places APISOC 2 Type II / ISO 27001
- TypeSafe AIDocument-type classification on masked document text; does not train on customer data
- UpstashDistributed rate-limit countersSOC 2 Type II
- GitHubSource code and CISOC 2 Type II
- SentryError monitoring; PII is scrubbed before transmissionSOC 2 Type II
Section 11
Responsible disclosure
If you believe you've found a security vulnerability in AppWiz, please report it privately to security@nycappwiz.com. We will acknowledge your report within two business days and keep you informed as we investigate. Please give us a reasonable window to remediate before any public disclosure. We do not currently run a paid bug-bounty program, but we publicly credit researchers who help us improve.
Section 12
Contact and full policy
Our full Information Security Policy — including roles, data classification, change management, backup and recovery, vendor review cadence, and the complete incident-response procedure — is available on request. Please email security@nycappwiz.com with the name of your organization and the reason for the request (vendor review, audit, due diligence, etc.) and we'll send a copy promptly.
For privacy-specific inquiries, see our Privacy Policy. For data processing terms, see our DPA.
Doing a vendor review?
Send your client the one-page overview, or ask us for the full policy.