Answers your IT reviewer can check

PDPA or GDPR compliance.

• A privacy notice is published, stating the purpose and lawful basis of processing, the categories of data held, retention, the rights of the data subject with the place each is exercised, cross-border transfer, and a monitored contact channel for rights requests.
• Deletion on request is implemented end to end: identity re-check, a retention window during which the user may cancel, then permanent deletion by an automated process.
• A record is kept of each acceptance of a published document edition, and users can obtain a copy of their own personal data from the Account page.
• A personal data breach notification procedure and a record of processing activities are maintained internally.
• All six sub-processors are covered by a data processing agreement: two accepted or executed explicitly with the provider, and the remainder incorporated automatically into the terms under which each service is used.

PCI DSS Compliance. (Notes: If system has credit card payment function, this shall be concerned)

• This item applies only where the system has a credit card payment function.
• The product has no payment functionality and never handles cardholder data, so the requirement does not arise.

Personal or Sensitive data encryption. (Notes: If system has personal or sensitive information, this shall be concerned)

• TLS in transit on every route, with HSTS (two-year max-age, includeSubDomains, preload).
• Encryption at rest is provided by the database and object-storage platforms.
• Passwords are hashed with bcrypt over a SHA-256 pre-hash.

Penetration test annually and before production deployment with at least OWASP 2021.

• A full internal security audit was completed against OWASP Top 10:2021, OWASP API Security Top 10:2023 and OWASP ASVS 5.0 Level 2, with every finding documented and a regression test accompanying every fix.
• External penetration testing falls outside the current scope of service and can be arranged on request.

To enhance the security of critical systems, access control has been implemented. This includes options for MFA or VPN (if available).

• Role-based access control with an administrator-editable permission matrix, enforced server-side.
• Email one-time-password step-up authentication is enforced at sign-in.

Audit trail tracability / log of customer information or sensitive information if change occurred within a system.

• Authentication events, document workflow transitions, outbound email, defect history and authorization denials are each recorded.
• Authentication events are retained for one year.

Separate environment for production and development / testing for all modules.

Production and sandbox run on separate databases and separate deployments.

DRP site already in place, with annual test or not implement.

• Recovery does not depend on any single provider or region.
• Application hosting, the database and file storage each run on an independent provider, and a complete copy of the database is exported to storage held by a different provider, in a different country from the database itself.
• A written disaster recovery plan is maintained, covering recovery objectives, failure scenarios, responsible roles and customer communication.
• Within the database platform, recovery is available through point-in-time restore to any chosen moment within a 7-day window, and daily snapshots retained for 30 days.
• A recovery exercise was carried out on 2026-08-27 against the copy held outside the database provider: it was restored into an empty database in a different region, starting with no tables at all, and reproduced all 183 tables and 1,808,737 rows with no missing rows, no foreign key violations, and no value mismatches in the sampled verification.
• The database recovery itself took 11 minutes.
• The exercise follows a documented, automated procedure, so every run performs the same steps and leaves a dated record, and it is carried out at least once every 12 months.
• The recovery time objective for the service as a whole is 4 hours, covering database restoration and application redeployment.
• That objective is wider than the exercise above, which measured the database restoration only and did not redeploy the application, re-point DNS, or restore file storage.
• No standby recovery site is maintained: recovery is achieved by provisioning in an alternate region and restoring, which is what the exercise measures.

Acceptable SLA of support (Problem & incident management, Change request management) by IT support / system owner.

• Response within 8 business hours for urgent issues (service unavailable, data corruption, security vulnerability) and within 48 business hours for all other issues and change requests.
• These are response commitments, not resolution commitments.

Subcontractor risk management (if applicable): inform the client before engaging, do risk assessment, vendor shall be responsible for loss / delay / unexpected result.

• Six sub-processors are used.
• Each is named in the privacy policy, together with its purpose and the data it receives.
• Each is risk-assessed before engagement, and the assessment is reviewed annually.
• The customer is informed in writing at least 30 days before a sub-processor is engaged or replaced, with the opportunity to object.
• Responsibility to the customer for sub-processor performance — including loss, delay, or unintended result — is accepted, limited in aggregate to the service fees paid in the preceding 12 months.
• All six sub-processors are covered by a data processing agreement: two accepted or executed explicitly with the provider, and the remainder incorporated automatically into the terms under which each service is used.

Backup and Restoration Service included in vendor services, or if required to be performed by the client, vendor shall provide detailed procedure and backup media handling procedures. Annual backup and restoration test is included in vendor service.

• Backups are performed automatically and continuously by the platform providers: the database with point-in-time restore to any chosen moment within a 7-day window plus daily snapshots retained for 30 days, and file storage with a soft-delete window of at least 7 days on every bucket.
• Restoration is exercised, not merely described: on 2026-08-27 the copy held outside the database provider was restored into an empty database in a different region, reproducing all 183 tables and 1,808,737 rows with no missing rows, no foreign key violations, and no value mismatches in the sampled verification, in 11 minutes.
• The exercise follows a documented, automated procedure, so every run performs the same steps and leaves a dated record, and it is carried out at least once every 12 months.
• The recovery time objective for the service as a whole is 4 hours, covering database restoration and application redeployment; the exercise measures the database restoration only.

For system implementation which is NON-SAAS / PAAS / IAAS, the vendor shall deliver source code, design document, data entity design, developer training.

The product is delivered as hosted software-as-a-service, so the deliverables listed in this item do not apply.

Having Manage Access: logical access management, e.g. different levels of system access, high-privilege access segregation from normal access permission; physical access to system resources and utilities having an access request procedure.

• Logical access is segregated by role and verified against ASVS Chapter 8 with zero findings.
• Physical access is handled by the certified cloud providers named in the privacy policy; no physical infrastructure is under vendor control.

Service contract is not automatically renewed — not auto-continue of contract for non-critical service / system, or auto-continue of contract for critical service / system.

Governed by the service agreement; the contract does not renew automatically.

Requirement change management process (e.g. request / approval), documentation, tracking, monitoring is in place.

Requests are tracked, approved and recorded through issue tracking, a review workflow, and written records kept under version control.

Delivery of user training.

• The product includes an in-application Help module: manuals and release notes with attached files.
• A read-only view of the permission matrix, generated from the rules the system actually enforces.
• Workflow diagrams generated from live configuration for every document type.

API interface.

• A closed, customer-scoped integration API is available, on a versioned path.
• It is not a public API: there is no self-registration and no public entry point.
• Access requires a credential issued by the vendor for one specific project, together with a separate project-level switch that the vendor enables on request.
• Both are off until requested, and turning the switch off immediately withdraws access for every credential issued to that project.
• The API is read-only and returns metadata only: the project record, the document types configured for it, and its documents’ identifiers, status, version and current workflow state, individually or as a paginated list.
• It never returns a document’s content, its attachments, its files, or a link to any of them.
• Every response is scoped to the requesting project in the database query itself rather than by any value the caller supplies, so a request for another project’s record returns the same result as a request for a record that does not exist.
• Authenticated calls are recorded in an audit trail, and failed authentication is rate-limited without revealing which part of a presented credential was wrong.

Implementing endpoint protection such as Endpoint Detection and Response (EDR) tools or anti-virus solution in your organization.

• Endpoint detection and response (EDR) protection is deployed on organisation endpoints.
• Servers are managed cloud services whose endpoint protection is the provider's responsibility.

Control over access to job scheduling and job scheduling procedures.

Scheduled jobs are defined in version control and changed only through authorised deployment.

Your platform can provide User Administration flexibility: user can self-manage password.

Users reset and change their own passwords; password managers and paste are supported.

Does your AI solution use our data for training outside our organization or share it with other customers — to train or improve AI models deployed or sold to other organizations, to share insights, patterns or outputs derived from the data with any external party, or to include the data in aggregated datasets for benchmarking, analytics or product development?

• Customer data is never used to train or improve AI models, is never shared with other customers or with any other external party for that purpose, and is never included in an aggregated dataset for benchmarking, analytics or product development.
• AI-assisted features are opt-in, per project, and off by default.
• Before any data is sent to the third-party model provider, direct identifiers (names, email addresses, phone numbers) and organisation names are automatically removed and replaced with placeholders; financial figures are removed using the same rule the application already applies to hide monetary values from unauthorised users.