You are trusting us with the information that drives your funding, and with data about the people you serve. Everything on this page describes controls that are live and tested in our platform today, not planned. Where something is still being built, we say so in plain language.
Read the public Subprocessor Disclosure, or jump to our security posture and the honest limits.
Names and contact details of the people you serve are the most sensitive data you hold, and often legally protected. Our answer: we are built so we do not hold them in any form our team can read.
Your grant pipeline, briefs, and financials are competitively vital, and you need us to work with them. Our answer: least privilege access you can watch.
When someone fills out one of your forms, any identifying fields are split off at the moment of collection into a separate identity vault, and the working record gets a code (like P-4X7K2). Everything downstream, analysis, reporting, and drafting, runs on codes.
Good rules need enforcement, so the platform screens everything on the way in. Every request, note, and file upload is checked server side for participant identifying patterns, such as lists of names, Social Security numbers, date of birth columns, and contact sheet spreadsheets. Flagged items are rejected before anything is stored. Nothing is retained, even briefly. The rejection explains what was detected and shows the right path (coded forms, or a de-identified re-upload). PDF and image files cannot be content screened, so uploading one requires you to confirm it contains no participant identifying information.
Our platform runs on a small set of United States based providers, each named in our public Subprocessor Disclosure:
We are not in house, and honestly, neither are the spreadsheets, form tools, and email that most organizations’ data lives in today. The real question is whose controls are stronger. Ours are listed on this page, and they are verifiable.
Nonprofits serving vulnerable people worry about legal process reaching participant identities. Our architecture is built to limit that exposure.
If we receive a legal demand touching your data, we notify you where the law allows, so your counsel can respond.
We are an early stage company. We do not have a SOC 2 attestation yet, and we will never imply that we do. Our platform is built on SOC 2 aligned architecture, and a formal audit is on our near term roadmap.
Here is what we do have today:
The full controls register, with an honest status on every control, is our Client Portal Security Program. We will complete your security questionnaire on request: support@lilxhub.com.
Trust built on overstatement is not trust. So we state our limits plainly.
No form, no email wall. These are public. A Business Associate Agreement is available for HIPAA covered entities on request.
Data classes, prohibited uses, a 72 hour breach notification commitment, and deletion schedules.
Exactly what our AI touches, and what it never touches.
The coded-data rule and how participant information may enter the platform.
Every provider that may process client data, what each can reach, and our 30 day change notice.
Also in the legal family: our Terms of Service, Privacy Policy, and the Client Portal Security Program.
For security questions, a security questionnaire, or a copy of any document above, write to support@lilxhub.com.
If you believe you have found a security vulnerability, please report it to support@lilxhub.com with enough detail to reproduce it. Please do not access, alter, or exfiltrate any data beyond what is needed to demonstrate the issue, and give us a reasonable window to respond before public disclosure. We will acknowledge your report and keep you updated as we investigate.