The evidence behind the platform.
Wēlr serves regulated equipment-service teams, so our own controls have to hold up to the same scrutiny we help our customers pass. This page is the single place to see our security posture, attestation status, penetration-testing program, sub-processors, and data-processing terms — stated plainly, with no claim we can't back up.
What we comply with, and the state of each.
Status is shown verbatim. Attained means a third party has issued a report or certificate we can hand you today — nothing on this page currently carries that status. Designed-for means the architecture is built to the standard and tested against it internally, but no third party has assessed or certified it. Planned means it is on our roadmap and no engagement has been signed yet — where we have committed to a target date, the card states it; where we have not, the card says no date is committed rather than supplying one.
Quality-system requirements are enforced architecturally — immutable audit trails, document control, and separation of duties at the model and view layer.
Electronic records and signatures: attributable, time-stamped, append-only, with signature-binding enforced in code.
Medical-device quality-management practices are reflected in the platform’s document and change-control workflows. Wēlr is not ISO 13485 certified and holds no ISO 9001, IATF 16949, or AS9100D certification.
No SOC 2 report exists and no audit engagement is signed. The underlying controls are built and tested on every change (see below). Our roadmap targets audit commencement in Q3 2026 and a Type I report in Q1 2027, with Type II following the observation window. We will not describe an audit as underway before one starts.
Not certified. No certification body has been engaged and no target date is currently committed. The control evidence assembled for the SOC 2 track is intended to be reusable if an ISO 27001 track is commissioned.
Controlled-data classification tiers and ITAR/EAR/CUI labelling are implemented and wired through the API, serializer, and signal layers. Redaction is wired into the outbound classification gate, which returns an allow, redact, or block verdict and fails closed on an organization mismatch. Because no production environment is deployed, these controls have been exercised in development and in the test suite but have never run against production data. Wēlr holds no CMMC certification, has no FedRAMP authorization, and no assessor has reviewed this posture.
PHI is not required to use Wēlr and should not be submitted to the platform today. There is no HIPAA-eligible deployment, no production environment, and no Business Associate Agreement with any sub-processor; whether we will offer a BAA at all is an open decision. We do not assert blanket HIPAA compliance and hold no HITRUST certification.
We do not claim HIPAA compliance. Wēlr does not require Protected Health Information to function, and PHI should not be submitted to the platform today: we have no HIPAA-eligible deployment, no production environment, and no Business Associate Agreement with any sub-processor. Whether we will offer a BAA at all is an open decision, not a form waiting to be signed. If your use case involves incidental PHI, write to security@we-lr.com and we will tell you plainly where that stands.
Controls enforced in code, not just in policy.
Envelope encryption for designated sensitive fields.
Designated sensitive fields — work-order problem context, ERP and MES integration credentials, equipment message payloads, and profile identifiers such as date of birth — are stored envelope-encrypted: a per-tenant data key wrapped by a master key. This is field-level protection on named columns, not blanket encryption of all tenant data, and the accompanying key-rotation and rollback routines are operator-invoked rather than automatic. All of it is implemented and tested in code and none of it has been exercised in a production environment, because none is deployed: the working key backend today is a local master-key file, and the managed-KMS backends (AWS KMS, Azure Key Vault) are declared but not yet implemented. TLS 1.2+ in transit and full-disk and database-level AES-256 at rest are requirements of our reference deployment architecture — configuration of a running environment rather than code — and no such environment exists yet.
Least-privilege access by default.
Role-based access control across ten roles with mandatory least-privilege defaults, enforced in the application. SSO + MFA gating and logging of administrative access are specified in our access-control policy, which is itself a draft pending compliance-officer and counsel review; they become evidenced controls when a production environment exists to evidence them in.
Immutable, attributable audit trails.
Audit-log records are append-only — no update() or delete() is exposed at the model layer, including to Wēlr personnel. The same constraint that stops your team rewriting history stops ours.
Separation of duties enforced structurally.
Creator ≠ approver and executor ≠ approver are checked at the database constraint, model, and view layers — not just documented in a policy.
Tenant isolation at the database.
Multi-tenant data is isolated with PostgreSQL row-level security, with a tenant context set per request — not just a WHERE clause in application code.
| UTC | Actor | Action | Detail | Object |
|---|---|---|---|---|
| 14:06:40Z | system — | export | Evidence package assembled from the trace below | PKG-2891 |
| 14:02:11Z | M. Reyes Service Engineer | execute | Captured cryogen pressure 0.62 psig | WO-00342818 · §05 |
| 14:01:55Z | M. Reyes Service Engineer | execute | Scanned lockout LK-7831 | WO-00342818 · §04 |
| 13:58:02Z | K. Davis Manager | approve | Rev 4.2 promoted to live — approver ≠ author | PROC-MRL-118 |
| 13:52:44Z | S. Whelan Tech Writer | blocked | Self-approval refused — author cannot approve | PROC-MRL-118 |
| 13:48:07Z | S. Whelan Tech Writer | create | Rev 4.2 drafted from source p.118 | PROC-MRL-118 |
Audit log · illustrative example · not live data
The rows above are fabricated to show the shape of an audit record — the actors, timestamps, and object identifiers are invented. They are not a view of a running system. No production environment is deployed, so there is no live audit log to preview.
One layer running today, and one we have not yet commissioned.
We treat a security control the same way we treat a compliance control — it isn't real until something tries to break it on a schedule. That standard applies to our own claims too, which is why the second card below says what it says.
Internal Attack-Pattern Suite
A dedicated attack-pattern test suite runs in CI against the application on every pull request and every merge to the main branch. It exercises the controls an attacker would target first: RBAC bypass and role escalation, cross-organization data leakage, audit-log immutability tampering, terminal-state transitions, row-level-security isolation, encrypted-field exfiltration, separation-of-duties (creator ≠ approver) violations, electronic-signature attacks, and classification-tier escalation. This is application-level control testing, not a network or infrastructure penetration test.
- 123attack tests
- 12attack modules
- every PRCI cadence
A control regression — any attack that newly succeeds — fails the build and blocks the merge, and is triaged before the change can land. A generated control narrative documents which control each test maps to. Counts are taken from auth/backend/pen_tests/tests/ on July 31, 2026, excluding the four meta-tests that cover the suite's own report generator rather than an attack surface; counting those in gives 127 tests across 13 modules. This is application-control testing in CI, not evidence from a running production system — there isn't one yet.
Third-Party Penetration Test
No third-party penetration test has been performed. An earlier version of this page described an annual external engagement; there was no engagement and no report behind that statement, so we removed it rather than leave it standing. A first external engagement follows the deployment of a production environment for it to test, and sits alongside SOC 2 audit preparation. We have not committed to a date, and we would rather publish none than one a procurement team will diary and hold us to.
When an engagement completes, the summary letter — scope, methodology, finding severity counts, and remediation status — becomes the customer-facing artifact, and the full technical report is shared under NDA. Until then there is nothing to request, and we would rather say so than keep a placeholder here.
The vendor categories that will touch customer data.
No production environment is deployed, so no vendor is processing customer platform data today. The categories below are the ones our reference architecture depends on, plus the optional external model provider that platform content can be transmitted to when the AI-assisted features are enabled — we list it here because a reader deciding whether to trust us should not have to find that out later. These are the categories a signed DPA will enumerate. The specific named list is provided to customers before any data is processed, and kept current from then on.
Cloud infrastructure (planned)
Compute, storage, and the primary PostgreSQL database. A United States region is intended. No provider is committed, none is deployed, and our infrastructure definition has never been applied.
Email delivery
Transactional email and inquiry response. Does not receive customer platform records.
Customer-relationship management
Sales pipeline only — marketing-site inquiries. Not used for product data.
Error tracking & uptime monitoring (planned)
Operational diagnostics and availability monitoring with data-minimized payloads. No monitoring or alerting system of record is deployed and no vendor is committed.
AI / large-language-model provider (optional)
Model-assisted authoring, search summarization, and troubleshooting. Off unless expressly enabled. The default configured provider is OpenAI, with Azure OpenAI, AWS Bedrock, and Anthropic as configurable alternatives. Both model-calling paths are routed through a classification egress gate that screens each payload and returns an allow, redact, or block verdict before transmission; it fails closed on an organization mismatch and on non-text payload parts. Because no production environment is deployed, the gate has been exercised in development and in the test suite but has never run against production data. The specific provider is named in the DPA before any data is processed.
Platform customers receive advance written notice before we add a sub-processor that handles their data. The notice period and the objection rights that go with it are set in the DPA accompanying the subscription, not fixed by this page. No named list exists yet — no vendor is committed and nothing is deployed — so an enquiry to privacy@we-lr.com gets the current status rather than a document.
Data Processing Addendum & trust artifacts.
The documents below are released to prospective and active customers. Where an artifact does not exist yet, the row says so instead of offering it — the request still works, and we answer with the current status and the target date rather than a placeholder.
For platform customers, the Master Services Agreement and the DPA accompanying your subscription control where they conflict with anything stated on this page.
If something goes wrong, you hear it from us.
We have a written incident-response policy with defined severity tiers and escalation paths. It is a draft pending compliance-officer and counsel review, and the named on-call rotation is not yet staffed — we will not call it operational until it is. Specific breach-notification timelines and incident-response commitments for platform customers are written into the MSA and DPA — not left to this page — so they are contractually binding rather than aspirational.
Security & trust contacts
- Security disclosures & reportssecurity@we-lr.com
- Privacy & sub-processor requestsprivacy@we-lr.com
- Generalhello@we-lr.com
Found a vulnerability? Report it to security@we-lr.com. We acknowledge good-faith reports and will not pursue action against researchers who follow coordinated-disclosure practice.
Need our trust package for vendor review?
Prospective customers can request the compliance roadmap memo, the control documentation behind the attack-pattern suite, and the draft DPA in one bundle — with every gap stated plainly, including the sub-processor categories we have not yet been able to name.
Welr LLC · Delaware