How We Think About Privacy at Inori

Inori processes insurance certificates on behalf of contractors, property managers, and construction firms. That means we handle documents that contain business names, policy limits, endorsement language, and the names of individuals responsible for coverage.

This is sensitive information. Not in the sense that it's secret — most of it is shared deliberately between contracting parties — but in the sense that it belongs to someone, and handling it well is a professional obligation.

Here's how we think about it.

Data minimization as a design constraint

Before we collect a piece of data, we ask: do we actually need this? Not "could this be useful someday," but "does this serve a specific function in the product today?"

The answer has to be yes, or we don't collect it.

In practice, this means we don't collect payment card numbers (Stripe handles that), we don't store raw PDF content longer than needed for analysis, and we don't ask for information about your vendors that isn't required for compliance tracking.

Retention that matches what we publish

Our Privacy Policy says data is retained for 90 days after account deletion before permanent purge. We mean that literally — there's a scheduled cron job in the codebase that enforces it. The policy and the code agree.

This matters because privacy policies that describe behavior the software doesn't actually implement aren't just misleading — they create legal exposure under FTC § 5 (unfair or deceptive practices). We've written the cron before the policy clause, not after.

GPC as a real opt-out signal

If your browser or extension sends a Sec-GPC: 1 header (Global Privacy Control), we honor it automatically. Our middleware reads the header, persists a cookie, and disables PostHog and Sentry session capture for that user. No settings page required.

We do this because the CCPA and CPRA treat GPC as a valid opt-out of sale or sharing of personal information. More practically: if you've expressed a privacy preference at the browser level, you shouldn't have to express it again in every app you use.

Sub-processors we've documented

We use a small set of third-party services, and we list all of them in our Data Processing Agreement. As of April 2026, that includes Supabase (database), Stripe (payments), Anthropic (AI analysis), PostHog (analytics), Sentry (error monitoring), and Resend (email).

PostHog and Sentry are the ones that trigger the most questions, because they process session-level data that may incidentally include email addresses or tenant identifiers. Both offer EU data residency options. Both are configurable for anonymization. We've documented retention periods and added them to the DPA sub-processor list so customers can make an informed decision.

Data subject requests without a support ticket

You can request access to, correction of, deletion of, or export of your data directly from Settings → Privacy. Requests are logged in our system with a 30-day SLA. We respond within that window — not just as a policy commitment but because the tracking is automated.

If you're a vendor whose data is being tracked by one of our customers (rather than a direct user of the product), you can submit a request by emailing ask@askinori.com with subject line "Privacy Request — [type]."

What we're still building

We're a small team, and we've made deliberate tradeoffs about what to build now versus later.

Things that are deferred until we have the right triggers (first enterprise RFP, first CA/CO/VA prospect asking explicitly, SOC 2 Type II kickoff):

• Automated DSAR response with identity verification (currently manual after submission)
• State-specific breach notification automation (currently playbook-based)
• SOC 2 Type II audit artifacts

We track these openly as a GitHub issue — not because it's required, but because we think it's the honest way to communicate about compliance work that's genuinely in progress versus work that's complete.

---

Questions or concerns about how we handle your data? Email ask@askinori.com.