Syntext security and compliance: a public due-diligence overview

Syntext is ISO 27001 certified and SOC 2 compliant. This public guide explains the credentials, product controls and implementation practices that protect your documents and data.

For confidential certificates and reports, use the documentation request on our Security and Compliance page.

Review credentials in context

Syntext has an ISO 27001 certified information security management system (ISMS). Syntext is SOC 2 compliant and GDPR compliant, with independently audited controls and responsible personal-data handling.

ISO/IEC 27001 defines requirements for an ISMS and an organisational approach to managing information-security risk. Buyers should verify the certificate’s issuer, scope, edition, period and applicability in the evidence supplied for review.

AICPA describes SOC 2 as a controls-reporting engagement related to selected trust-services criteria. Verify the report type, auditor, period, scope and included criteria in the documentation provided for review.

GDPR is a regulatory framework. The applicable roles, instructions and obligations depend on the actual processing arrangement and should be reviewed for that use case.

Connect controls to the product

Product-level questions differ by use case:

• Syntext Scribe: Scribe supports MFA. Review browser and API access, account responsibilities, usage controls and the document process receiving its output.
• AP Automate: role and entity access boundaries are part of the product scope. SSO and SAML requirements are agreed with the buyer’s IT team during implementation.
• Syntext Flow: review the configured triggers, email exchanges, file or API handoffs, progress visibility and ownership of human exceptions.

Our implementation team configures the relevant controls around your workflow and agrees operating responsibilities with your team.

Map data handling before live use

Draw the intended data flow from source to destination. Identify the systems involved, the data exchanged, the access method and the party responsible for each step.

The European Data Protection Board’s controller and processor explanation distinguishes the party deciding why and how personal data is processed from a processor acting on documented instructions. Apply the relevant roles to the real arrangement with appropriate legal advice; do not assume them from a product label.

Questions for the implementation review include:

• Which party acts as controller or processor for each activity?
• Where will processing occur, and which approved subprocessors or services are involved?
• What instructions, contractual terms and access responsibilities apply?
• What retention, deletion, backup and review requirements must the configuration support?
• How are integration failures, access changes and incidents escalated?

Confirm data location, encryption arrangements and applicable legal obligations against current evidence for the proposed scope.

Review access and operational ownership

Agree who can administer the product, submit or view source documents, inspect results, resolve exceptions and change configuration. Keep service accounts and API credentials within the buyer’s approved access-management process.

For every interface, define authentication, authorisation, least-access expectations, logging, error handling and ownership. For every human review step, define who can release, correct or reject the work.

Our security approach extends into day-to-day operations: access reviews, configuration changes, failed exchanges and offboarding all need clear ownership.

Keep public guidance and confidential evidence separate

This page and the Security and compliance overview are public buyer guidance. They provide context for a first review but do not expose certificates, SOC reports, penetration-test material, contracts or other confidential evidence as unrestricted downloads.

Prospects, existing customers and legal or advisory teams can request relevant documentation through the security page. Syntext reviews the relationship, requested material and intended review manually. A request does not guarantee immediate approval or delivery.

Prepare a useful due-diligence request

Before requesting documents, describe the product and workflow in scope, the systems exchanging data, the intended user groups and the questions the review must answer. Name the categories of evidence required rather than asking for an undefined “security pack”.

Then compare the supplied evidence with the proposed implementation. Confirm dates, scope, issuer or auditor details and any reliance restrictions directly in the documents. Record unresolved questions with an owner before live data moves.

Use the security documentation request for a manually screened request, or book free initial discovery to discuss the product and implementation context first.