A security model stated precisely enough to argue with.
TLS, MFA, secure cookies, and a WAF are table stakes and are in place. They are not the interesting part, and a page that leads with them is telling you it has nothing else to say. What follows is the part that was engineered.
Tenant isolation
A tenant is the unit of reach. Membership decides which records a user can address at all, and entitlements are granted per tenant, not globally, so a new module is a grant instead of an exposure.
- Per-tenant membership and per-tenant module entitlements
- Tenant-scoped records across every module
- Subscription and trial state held per tenant
Environment separation
Inside a tenant, demonstration data and operating data are different worlds. Requests carry the environment they act in, and records are scoped to it. A demo can never contaminate a decision record.
- Environment-scoped data model
- Per-environment document, certification, and supplier-type definitions
- Object storage partitioned by tenant and environment
Controlled access
Sessions are held server-side and expire on a fixed schedule, so revocation is real, not advisory. Programmatic access uses scoped keys instead of borrowed user credentials.
- Email and password with optional TOTP two-factor
- Role-based permissions for administrative functions
- Server-side sessions with fixed expiry
- Scoped API keys for programmatic access
Evidence integrity
Evidence is append-only in effect. Every document is hashed on upload and superseding one creates a version instead of overwriting it. The decision made six months ago still points at the document it was actually made on.
- SHA-256 digest computed and stored at upload
- Versioning preserves superseded documents and their review state
- Evidence linked to the decisions that cite it
- Records anchored in an append-only SHA-256 chain, each entry chaining to the previous
Auditability
The question is never 'what does the system say now'. It is 'what did it say then, and on what basis'. Decision-relevant and security-relevant activity is retained so that question has an answer.
- Authentication and login event history
- Evidence review state and version history
- Case activity and decision records retained
- Webhook delivery history for integrated systems
External verification
Some claims have to be checkable by someone who will never have an account. A verification page is addressed by an unguessable token and exposes exactly one claim. Nothing about the tenant, the platform, or anything adjacent.
- Token-addressed public verification pages
- Verification tokens never returned by list endpoints without authorization
- Downloadable verification certificates
The narrowest possible public surface.
A verification page is the only part of IPAC an unauthenticated stranger can reach. It is addressed by an unguessable token, exposes exactly one claim, and reveals nothing about the tenant, the platform, or any adjacent record. Verification tokens are never returned by list endpoints without authorization.
- Origin
- Ecuador — Guayas
- HS code
- 1801.00.00
- Lot number
- LB-2291-C
- Processing plant
- Planta Vinces 04
- Certifications
- Organic · Fair Trade · HACCP
No account. No tenant data. One claim.
Public verification page at /verify/:token.
What we do not claim.
A security claim is only useful if it is precise. Everything below is something a competitor would leave for you to discover in week six of a procurement cycle. Here it is in minute one, so you can price it into the decision or walk away early.
- Single sign-on is not available.
- SAML and OIDC are not implemented. Authentication is email and password with optional TOTP two-factor.
- Anchoring is a hash chain, not a public blockchain.
- Records are anchored in an internal append-only SHA-256 chain. Nothing is written to an external or public distributed ledger.
- Isolation is enforced by query scoping.
- Tenant and environment separation is enforced in the application layer, not by physical database separation. We describe it that way instead of as an absolute guarantee.
- We do not hold an ISO 27001 certificate.
- SOC 2 is the attestation we hold. ISO 27001 is not in place, and control questions outside the SOC 2 scope are answered directly, in writing, during evaluation.
Deployment posture, data residency, and controls specific to a regulatory environment are scoped during evaluation. If you hold a control requirement not described here, raise it and you will get a direct answer, not a roadmap.
Independently examined under SOC 2 Type 1 and Type 2 by Sensiba.
- Criteria
- Security, Availability, and Confidentiality
- Type 2 period
- March 5 to June 5, 2024
- Service organization
- Schubring Global Solutions
Schubring Global Solutions, which operates the platform IPAC runs on, completed SOC 2 Type 1 and Type 2 examinations performed by Sensiba, an independent service auditor. The Type 2 examination covered the trust services criteria for Security, Availability, and Confidentiality across the period March 5 to June 5, 2024, testing whether the controls actually operated rather than whether they were merely designed well.
- The Type 2 period closed in June 2024 and has not yet been refreshed. A new examination is intended, and until it completes we describe the attestation in the past tense.
- Processing Integrity and Privacy were not in scope. The applicable criteria were Security, Availability, and Confidentiality.
- The report uses the carve-out method for the subservice organizations providing application maintenance and support, and assumes complementary user entity controls at your end. It identifies which.
Ask for the report at [email protected].
We would rather answer a hard security question early than late.
Send the questionnaire before the demo if that is the order that suits you. Direct inquiries reach us at [email protected].