Security Statement | GetZenta by Zenta Technologies

Section 01

Security Philosophy

GetZenta is built on the principle that digital evidence is only as strong as its trail. A receipt that was captured, processed, and stored without a traceable decision record is not audit-grade evidence — it is just a file.

Our security model is not designed primarily to satisfy a checklist. It is designed to support the core value proposition: that records passing through GetZenta carry a traceable decision history from capture to evidence lock.

🔒

Access Separation by Design

Organisation-scoped access controls, including database-level policies, are designed to keep each organisation's records separate — not just at the application layer.

🧠

Human Stays in Control

AI extracts and signals. Humans decide. AI is not designed to issue compliance determinations, evidence certification, or LHDN readiness status without human review and sign-off.

📜

Traceable by Design

Once an evidence record is locked, changes to its decision trail — including AI output, reviewer identity, override reason, and timestamp — are designed to be recorded as visible audit events.

🇲🇾

Malaysia-First Context

Design is informed by LHDN MyInvois workflows, PDPA 2010, Malaysian tax law, and the practical realities of MIA-registered audit workflows.

Built for Auditor Workflows SME Data Handling Role-Based Access No Overclaiming

Section 02

Data Residency & PDPA 2010 Design

GetZenta is designed with Malaysian compliance requirements in mind. Hosting choices reflect practical latency considerations for Malaysian users.

Primary Hosting Region

GetZenta's primary platform infrastructure is hosted in a Southeast Asia regional environment. This supports regional data processing, may improve latency for Malaysian users, and reduces unnecessary cross-border transfer for standard platform operations.

PDPA 2010 Design Principles

GetZenta is designed with Malaysia's Personal Data Protection Act 2010, as amended, in mind. The points below describe our approach across the principles and are not a statement of compliance:

General Principle: Personal data is intended to be collected and processed only for the specific, lawful purposes described in the Terms of Service and Privacy Policy
Notice and Choice Principle: Users are informed of what data is collected and how AI processing is used, including that AI outputs are intended to be subject to human review
Disclosure Principle: We do not intentionally disclose personal data to third parties beyond the sub-processor categories described in the Data Processing Policy, except as required by law
Security Principle: We aim to apply technical and organisational measures to protect data against loss, misuse, and unauthorised access — described in Sections 03 and 04
Retention Principle: Data is retained for the periods described in the Privacy Policy, subject to statutory requirements under the Income Tax Act 1967
Data Integrity Principle: We aim to support the accuracy of extracted data, with human review gates for records where AI confidence is insufficient
Access Principle: Data subjects may have rights of access and correction under PDPA 2010, exercisable via the data protection contact in Section 07

Cross-Border Processing

Some platform functions — specifically AI-powered OCR and receipt extraction — involve transmission to cloud AI services that may process data on infrastructure outside Malaysia and Singapore. This is disclosed in the Privacy Policy (Section 08) and the Data Processing Policy (Section 04). Where configuration options are available, we aim to limit provider-side data retention beyond the immediate inference request.

ℹ️

GetZenta does not claim full PDPA certification or independent audit certification of its PDPA compliance posture. These statements describe the platform's design intent and operating principles. For a formal compliance assessment, engage a qualified Malaysian data protection practitioner.

Section 03

Organisation-Scoped Access Controls

A key security property in a multi-tenant platform is workspace separation — keeping one organisation's records apart from another's.

GetZenta uses organisation-scoped access controls, including database-level access policies, designed to keep each organisation's records separate. The effectiveness of these controls depends on correct configuration and ongoing verification.

How Access Separation Is Designed to Work

Tables containing user or organisation data are intended to be protected by database-level access policies
Requests are intended to be evaluated against the authenticated user's organisation context
If the requesting identity does not match a record's organisation scope, the record is intended to be inaccessible
These controls are intended to provide defence-in-depth if an application-layer filtering error occurs. They are not a guarantee against every failure mode.

Role Scoping Within an Organisation

Within each organisation, access is further governed by role assignment. GetZenta's three roles carry distinct permission scopes:

Auditor: Read access across client workspaces assigned to the firm. Review and approval rights. Locked evidence records are not intended to be modified.
SME: Read and write access to their own organisation's workspace. Can submit receipts, add business purpose notes, and view their own evidence queue. Not intended to access other SME workspaces.
Staff: Restricted to receipt submission and queue management within the organisation they are assigned to. Not permitted to perform review approvals or access evidence trail history above their scope.

What This Means for Audit Firms

For MIA-registered audit firms using GetZenta's multi-tenant workspace: each SME client workspace is scoped to that client's organisation context. Your firm can access client workspaces you are explicitly assigned to — access to workspaces you are not assigned to is designed to be restricted by organisation-scoped controls.

🔒

Access separation is designed to operate at the database layer. Application-layer access controls add defence-in-depth. Administrative access is intended to be separately governed, logged, and restricted. We intend to verify these controls through testing; this statement is not a test report or certification.

Section 04

Encryption & Transport Security

GetZenta uses encryption in transit and at rest, relying on controls provided by its infrastructure providers, across the data pathways described below.

At Rest

Encryption at Rest

Stored data — including receipt images, extracted fields, audit trail records, and user data — is intended to be encrypted at rest using industry-standard encryption provided at the infrastructure layer by our hosting providers.

In Transit

Encryption in Transit

Communication between the user's device and GetZenta's backend, and between GetZenta and AI sub-processors and payment processors, is intended to use modern transport encryption (TLS). HTTP connections are redirected to HTTPS.

Auth

Session Management & Password Hashing

User sessions are managed using short-lived authenticated sessions. Passwords are hashed using industry-standard controls. Sessions are invalidated on logout and refreshed on re-authentication.

Files

Receipt Image Storage Security

Receipt and invoice images are intended to be stored in private object storage with organisation-scoped access policies. Time-limited access links are intended for controlled file access, and files are not intended to be publicly accessible. Link expiry limits the window of access for any authorised file request.

MFA

Multi-Factor Authentication

Multi-factor authentication is intended to be available for platform users and is recommended for Auditor-role accounts. We intend to require it for Zenta Technologies administrative access to production systems, with administrative sessions logged and reviewed.

Section 05

ISA 230 & ISA 500 Audit Support

GetZenta is designed to support — not replace — the professional audit standards applied by MIA-registered auditors. The platform's evidence architecture is informed by ISA 230 (audit documentation) and ISA 500 (audit evidence) principles.

Standard	Relevant Principle	How GetZenta Supports It	Status
ISA 230	Audit documentation — timely preparation and completeness	Review actions, overrides, and decisions are designed to be timestamped and recorded in the evidence trail. System events and human judgments are designed to be kept separate and traceable.	Designed to support
ISA 230	Working paper assembly and retention	Evidence records, review decisions, and exception reasons are designed to be exportable as structured data (CSV / JSON) for inclusion in audit working papers.	Designed to support
ISA 500	Sufficiency and appropriateness of audit evidence	AI confidence scores and risk signals help reviewers assess evidence quality. Low-confidence extractions are designed to be flagged for human confirmation. Whether evidence is sufficient and appropriate remains the reviewer's professional judgment.	Reviewer support
ISA 500	Source document traceability	Original receipt images are retained alongside extracted fields and review decisions, subject to the retention terms, allowing reference back to the source document.	Designed to support
ISA 320	Materiality in planning and performing an audit	Materiality thresholds are designed to be configurable per engagement. Records above the materiality threshold are designed to be routed to the review gate regardless of AI confidence level.	Partial

⚠️

GetZenta supports audit workflows — it does not perform audits. ISA compliance, audit opinion, and professional judgment remain entirely with the MIA-registered auditor. GetZenta provides infrastructure; the auditor provides the professional standard.

Section 06

LHDN MyInvois Workflow Controls

GetZenta's receipt capture and evidence workflow is designed with Malaysian e-Invoicing workflows under the LHDN MyInvois framework in mind. These controls describe how the platform handles LHDN-relevant data and readiness states.

Receipt Data Structuring for MyInvois

When a receipt is processed through GetZenta, the AI extraction pipeline aims to extract fields commonly relevant to LHDN MyInvois-related workflows:

Merchant name and Tax Identification Number (TIN) where available
Business Registration Number (BRN) of the supplier
Transaction date, total amount, and tax breakdown (SST / service tax)
Invoice or receipt reference number
Classification of transaction type for MyInvois routing purposes

Threshold-Aware Routing

GetZenta applies configurable threshold logic to route records for human review based on transaction value. By default, high-value transactions above a configured materiality threshold are designed to be sent to the review gate regardless of AI extraction confidence. This is intended to help ensure that the records most material to LHDN-related workflows receive human attention before export or submission preparation.

Review Gates Before Export

Records are designed to progress to "Export Ready" status in GetZenta only through one of two paths:

High-confidence path: AI extraction confidence above threshold, no risk flags, no materiality trigger — User confirms and record is marked Evidence Ready
Review gate path: Any record flagged by confidence score, risk signal, related-party indicator, or materiality threshold is designed to require explicit human review and approval before export readiness is granted

AI is not designed to independently grant LHDN submission readiness; that step is intended to require human sign-off. Internal statuses such as Evidence Ready or Export Ready describe GetZenta's workflow only. They do not establish official LHDN MyInvois validation, acceptance or tax deductibility.

Export Formats

Records approved as Evidence Ready can be exported in CSV format structured for downstream LHDN MyInvois workflow preparation. The export includes extracted fields, review status, reviewer identity, and approval timestamp — intended to provide a traceable record for each transaction.

🏛

LHDN MyInvois

Workflow support

⚖️

Threshold Routing

Materiality-aware

👤

Human Gate

Intended before export

📋

CSV Export

With review details

🔒

Traceable Trail

Review history recorded

🇲🇾

Malaysia-First

LHDN field mapping

Section 07

Responsible Disclosure & Contact

Zenta Technologies welcomes responsible disclosure of security vulnerabilities in the GetZenta platform. If you believe you have found a security issue, we ask that you contact us privately before public disclosure to allow us time to investigate and remediate.

Responsible Disclosure Guidelines

Contact us at dpo@getzenta.com.my with a clear description of the vulnerability and steps to reproduce
Do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the vulnerability
Do not perform denial-of-service testing or social engineering against our staff or users
Allow us a reasonable period — up to 30 days — to investigate and respond before public disclosure
We will acknowledge your report within 3 business days and keep you informed of our progress

Scope

In-scope: production GetZenta web properties and associated APIs. Out-of-scope: social engineering, physical security, third-party sub-processor infrastructure, and any testing that could impact real user data.

Security & Privacy Contact

🔐 Security disclosures: dpo@getzenta.com.my

📧 General enquiries: hello@getzenta.com.my

📞 General security contact is available via verified email channels only

📍 Kuala Lumpur, Malaysia

⏱ Acknowledgement within 3 business days

🚨

If you suspect your GetZenta account has been compromised or you have observed unauthorised access to your organisation's data, contact us immediately at dpo@getzenta.com.my. Do not wait. Change your password and revoke active sessions while you contact us.

Security &Audit Infrastructure Statement