8. Security & compliance

8.1 What security & compliance certifications does DE hold?

• ISO 27001
• SOC 2 Type II
• GDPR
• PCI

8.2 Where can I find the full schema and changelog?

The schema is discoverable via the GraphQL Docs panel in Apollo Studio (Apollo Sandbox). Panel visibility is role-gated; a token only sees the queries, mutations, and fields its role is authorized for; see 8.10 for how that mapping works.

Breaking changes are communicated to clients by email in advance (see Versioning & migrations).

8.3 How are internal credentials protected?

Credentials are stored encrypted and at rest in secure corporate systems with RBAC and MFA under ISMS procedures.

Note: this describes protection of Deal Engine's own internal/operational credentials (e.g. secrets, service accounts). For encryption of customer and passenger data, see 8.7.

8.4 What is Deal Engine's PCI DSS scope, and does integrating affect mine?

Deal Engine holds PCI DSS certification (see 8.1).

Who can see fopInfo[] fields for a given account is governed by role permissions; see 8.10.

8.5 Where is customer data processed and stored, and can I choose the region?

Deal Engine runs two regional tenants:

• US: AWS Oregon
• EU: AWS Frankfurt

A customer's data is processed and stored in their tenant's region only.

8.6 What is the data retention schedule, and how do data-subject requests work?

Deal Engine holds GDPR compliance (see 8.1).

Retention schedule, the data-subject request (DSR) process, and the DPA/subprocessor list are not yet published on this site; they are available on request via your account manager or Zendesk (see 8.12).

8.7 Is customer and passenger data encrypted in transit and at rest?

This is distinct from 8.3, which covers Deal Engine's own internal/operational credentials, not customer or passenger data.

• In transit: Yes. Customer and passenger data is encrypted in transit using TLS 1.3, for both API traffic and webhook deliveries.
• At rest: Yes. Customer and passenger data is stored in AWS Aurora RDS, encrypted at rest with AWS KMS-managed keys.

8.8 What is Deal Engine's incident and breach notification process?

Availability-related notices (clients are notified by email in case of major service incidents (see Performance & uptime)) are availability communications, not a security breach commitment. The two are separate.

The breach-notification SLA and the documented incident-response process are not yet published on this site; available on request via your account manager.

8.9 How does Deal Engine manage vulnerabilities, and how do I report one?

• Penetration testing cadence: Annually, by a third party.
• Vulnerability remediation SLA: Critical: 24 hours. High: 1 week. Low: 1 month.
• Vulnerability disclosure contact: A dedicated trust/security contact is not yet published; available on request via your account manager.

8.10 How does OnePoint's role-based access control map to API authorization?

Roles and their permissions are configured per account in OnePoint and documented in the Role & user guide. Two things are worth understanding precisely, because they are easy to over-read.

How API authorization actually works. Roles are granted permissions; a request's role determines which root operations (top-level queries and mutations) are available to it. Authorization is applied at the root-operation level, not per nested field: if your role lacks the permission for an operation, that operation is absent from the schema your token sees, so the request fails schema validation rather than returning an authorization error. That is why the Apollo Sandbox schema differs between roles (see Backend authentication).

Permission-gated operations are the exception, not the rule. Most operations require a valid token but are not additionally permission-gated. Do not assume a role is confined to a subset of the API simply because its OnePoint permission list is short; confirm the specific operations your role must be denied, in writing, with Deal Engine.

The operations known to be permission-gated today, by capability:

• MFA for native login: not available for native email + password login. MFA can be enforced through your own identity provider via SSO; see Backend authentication.
• Failed-login lockout: enforced on a rolling 24-hour window: 3 consecutive failures lock the account for 15 minutes, 4 for 1 hour, and 5 restrict it until an administrator re-enables it. A successful login clears the counter. This applies to native login and to SSO sign-in.
• Password policy:

8.11 Can I retrieve an audit trail of API and UI actions?

A customer-visible audit trail of API and UI actions is not yet published; available on request via your account manager. This is distinct from authentication/login audit logs (tracked separately as a gap in Backend authentication) and matters for the finance audit chain; see also traceability between Document, Quote, and Request in Relationship between Document, Request & Quote.

8.12 How do I request the certificates and audit reports themselves?

The badges in 8.1 link to public certification pages. For the underlying evidence, under NDA:

8.13 Where do I find the answer for a specific security questionnaire row?