Security
This page describes the security standards Censalis Inc. ("Censalis", "we", "us") applies to its supplier-management software: the application our customers install inside their own enterprise platform tenant to record, route and close the events their suppliers are obliged to report on open purchase orders, and the companion service for suppliers that prepares those submissions. Our customers are aerospace, defense and other regulated manufacturers, and their suppliers. The standards below are written for the people who review vendors on their behalf: information security, supply chain, supplier quality and platform administration teams.
1. Where the Software Runs
The installed application runs entirely inside the customer's own platform tenant. There is no vendor-hosted component behind it, no Censalis account remains in the customer's tenant after installation, and no scheduled or triggered code path contacts anything outside that tenant. The application makes no outbound network connections of any kind: no remote endpoints, no external scripts, fonts or images, no telemetry, and no analytics. Notifications leave only through the customer's own email deliverability. Customer records therefore never pass through Censalis systems, and the application stays within whatever accreditation boundary the customer's tenant already holds, including tenants provisioned for government work.
2. Identity and Access
The application adds no authentication of its own. Internal users sign in through the customer's existing single sign-on into the platform; suppliers sign in through the customer's existing supplier portal login. Access inside the application is granted by packaged, least-privilege permission sets, one per role (administrator, buyer, quality reviewer, site quality, receiving, read-only auditor, and the supplier community role), so a customer assigns only the access each role needs. Object and field access are delivered by those permission sets; record access follows the customer's own ownership, queue and sharing configuration. Fields that can carry technical detail are excluded from every permission set and disabled by a tenant-wide setting until the customer's administrator turns on both.
3. Isolation Between Suppliers
A supplier sees only its own records. Sharing is enforced by construction rather than by screen logic: every data access runs in the calling user's own security context, so the platform's record-level sharing decides what is visible, and results are stripped of any field the user may not read before they reach the browser. Before each release we test this with an adversary's eye: a supplier-side test user attempts to reach every other supplier's events, files, dispositions and authorizations through every component, page and endpoint the application exposes, and the release requires zero cross-supplier visibility.
4. Secure Development
- Standards. Code is written against the OWASP Top 10 and the platform vendor's published secure-coding guidance for installable applications: user-context data access throughout, field-level security enforced before data is returned, no dynamic queries built from concatenated input (bind variables only), output encoding in every component, and no client-side secrets.
- Static analysis. Every release candidate runs the platform's static code analyzer with its security rule set and ships only with zero critical or high findings.
- Tests. No feature ships without its automated tests. The application's behavior is defined by a machine-checkable domain model with a shared conformance fixture set, and every fixture passes before a milestone closes.
- Independent review. Before public listing, the application is submitted to the platform vendor's independent security review, and we maintain the review's questionnaire answers, permission inventory and data-flow documentation as living documents.
- Change control. All source is version-controlled with explicit, reviewed commits; production releases are cut only from the reviewed main line, and dependencies are pinned to exact versions.
- Secrets. Credentials and signing keys are held in a secrets manager and are never written into source code, tests, fixtures, documents or logs.
5. Data Handling and Classification
The application is designed so that a customer can run it without ever placing controlled technical data in it. Its always-on core holds identifiers, quantities, dates, statuses, decisions and the customer's own regulatory text. A separate technical-detail layer (discrepancy descriptions and images) exists but is off by default, and while it is off, technical fields and image uploads are refused with the customer's own warning text. File uploads are filtered by an extension allow-list and a size cap, and each upload records the uploader's acknowledgment of the customer's data handling warning. Regulatory and contractual clause text is always the customer's own words, loaded through configuration with its source named; Censalis authors none of it. Demonstration and test data are invented and are marked as such; no real supplier, part, person or customer record is used in development.
6. Encryption
All traffic between users and the application is encrypted in transit with TLS 1.2 or higher, under the customer's platform certificates. Data at rest is protected by the customer's platform encryption, and the application is compatible with the platform's customer-managed encryption features, so key ownership stays with the customer.
7. Audit Trail and Retention
Every event carries an append-only status log recording each transition, who made it and when. Field history is enabled on the fields that matter to an audit, original commitment dates are immutable (revisions are recorded as child rows), closed events are read-only except by administrator action, and configuration changes are captured in the platform's setup audit trail and in a packaged "Configuration changes" report. The application never deletes records automatically: retention is the customer's decision, and the application provides a report of events older than the customer's stated retention period to support the customer's own archiving.
8. Support and Vendor Access
Censalis has no access to customer tenants. Support is delivered through the customer's own administrators, working with masked data. Diagnostic exports contain structure only (counts, statuses, configuration) and never record content, and we do not accept controlled technical data through any support channel.
9. Our Hosted Services
The companion service for suppliers, and censalis.com, are hosted on Cloudflare's edge platform in the United States. Each supplier's data is isolated to its own account: every read and write is scoped to the authenticated account, and isolation across accounts is covered by automated tests. Outbound requests from the service pass through a single egress module with an allow-list and a log, so every byte that leaves a supplier's record is accounted for. Supplier data is never used to train machine learning models and is never sold.
10. Vulnerability Disclosure
We welcome reports from security researchers and customers. Report a suspected vulnerability to security@censalis.com. We acknowledge reports within 2 business days, keep the reporter informed as we investigate, and remediate by severity: critical issues as an emergency release, high within 30 days, and medium and low in the next scheduled release. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give us a reasonable time to fix an issue before disclosing it.
11. Incident Response
If we determine that a security incident has affected a customer's data, we notify the affected customers without undue delay, consistent with applicable law and contract, describing what happened, what data was involved, what we have done about it and what we recommend they do. Incidents are recorded, root-caused, and closed with a change that prevents recurrence.
12. Questions
Security questionnaires, architecture questions and requests for our review documentation go to security@censalis.com.
Censalis Inc.
1207 Delaware Ave, Suite 102
Wilmington, DE 19806