This page describes GetZenta's intended security architecture and operating principles. It is not an independent security certification, audit opinion, legal opinion, or tax advice. It is an honest account of how the platform is built and what controls are in place.
Last updated: 7 May 2026Operator: Zenta Technologies Sdn. Bhd. (202501060152)Regional Hosting: Southeast Asia
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 every record that passes through GetZenta carries a defensible, traceable, and tamper-evident history from capture to evidence lock.
🔒
Isolation by Design
Multi-tenant access control enforced at the database layer — not just at the application layer. Cross-tenant data leakage is structurally prevented.
🧠
Human Stays in Control
AI extracts and signals. Humans decide. No compliance determination, evidence certification, or LHDN readiness status is issued by AI without human review and sign-off.
📜
Immutable by Default
Once an evidence record is locked, its decision trail — including AI output, reviewer identity, override reason, and timestamp — cannot be silently altered.
🇲🇾
Malaysia-First Context
Every design decision is shaped by LHDN MyInvois requirements, PDPA 2010, Malaysian tax law, and the practical realities of MIA-registered audit workflows.
Auditor-Grade InfrastructureSME-Safe Data HandlingStaff Access ControlledNo Overclaiming
Section 02
Data Residency & PDPA 2010 Alignment
GetZenta is designed around Malaysian compliance requirements from the ground up. Data residency decisions reflect both regulatory alignment and 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, improves latency for Malaysian users, and reduces unnecessary cross-border transfer exposure for standard platform operations.
PDPA 2010 Design Principles
GetZenta is designed to operate in alignment with Malaysia's Personal Data Protection Act 2010 across the following principles:
General Principle: Personal data is collected and processed only for the specific, lawful purposes defined 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 the right to human review of AI outputs
Disclosure Principle: Personal data is not disclosed to third parties beyond the sub-processors listed in the Data Processing Policy
Security Principle: Technical and organisational measures are applied to protect data against loss, misuse, and unauthorised access — detailed in Sections 03 and 04
Retention Principle: Data is not retained beyond the periods defined in the Privacy Policy, subject to statutory requirements under the Income Tax Act 1967
Data Integrity Principle: Measures are in place to ensure accuracy of extracted data, with human review gates for records where AI confidence is insufficient
Access Principle: Data subjects have rights of access and correction under Section 30 of PDPA 2010, exercisable via the DPO contact in Section 07
Transient Cross-Border Processing
Some platform functions — specifically AI-powered OCR and receipt extraction — involve transient 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 controllable, we configure AI requests to minimise 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
Multi-Tenant Isolation Architecture
The most critical security property in a multi-tenant platform is workspace isolation — ensuring that one organisation's data is completely inaccessible to another organisation, even in the event of application-layer vulnerabilities.
GetZenta implements this at the database layer, not just the application layer, using database-enforced access controls.
How Tenant Isolation Works in GetZenta
Every table containing user or organisation data is protected by database-level access policies
Every request — regardless of how it originates — is evaluated against the authenticated user's organisation context
If the requesting identity does not match the record's organisation scope, the record is inaccessible — it is invisible, not just hidden
This means even if an application-layer bug allowed a request to run without proper filtering, the database-level control would still restrict access to the requesting organisation's records
Role Scoping Within an Organisation
Within each organisation, access is further governed by role assignment. GetZenta's three roles carry distinct permission scopes:
Auditor: Full read access across all client workspaces assigned to the firm. Review and approval rights. Cannot modify locked evidence records.
SME: Read and write access to their own organisation's workspace. Can submit receipts, add business purpose notes, and view their own evidence queue. Cannot access other SME workspaces.
Staff: Restricted to receipt submission and queue management within the organisation they are assigned to. Cannot 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 — other firms' workspaces are structurally inaccessible, not just restricted by a setting.
🔒
Tenant isolation is enforced at the database layer. Application-layer access controls add defence-in-depth, but database-enforced access policies remain the structural control. Administrative access is separately governed, logged, and restricted.
Section 04
Encryption & Transport Security
GetZenta applies encryption at rest and in transit across all data pathways — from the user's device to the database, and from the platform to AI sub-processors and payment gateways.
At Rest
AES-256 Encryption at Rest
All data stored in GetZenta — including receipt images, extracted fields, audit trail records, and user data — is encrypted at rest using industry-standard encryption. This is applied at the infrastructure layer and does not rely solely on application-level configuration.
In Transit
TLS 1.3 for All Data in Transit
All communication between the user's device and GetZenta's backend, between GetZenta and authorised AI sub-processors, and between GetZenta and payment processors is encrypted using modern transport security. HTTP connections are redirected to HTTPS.
Auth
JWT Session Tokens & Password Hashing
User sessions are managed using short-lived authenticated sessions. Passwords are protected using industry-standard hashing controls — plaintext passwords are never stored. Sessions are invalidated on logout and refreshed on re-authentication.
Files
Receipt Image Storage Security
Receipt and invoice images uploaded to GetZenta are stored in private object storage with organisation-scoped access policies. Time-limited access links are used for controlled file access — files are not publicly accessible by default. Link expiry limits the window of access for any authorised file request.
MFA
Multi-Factor Authentication
Multi-factor authentication is available for platform users and strongly recommended for Auditor-role accounts. Multi-factor authentication is enforced for Zenta Technologies administrative access to production systems. Administrative sessions are 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
Every review action, override, and decision is timestamped and preserved in the immutable evidence trail. System events and human judgments are kept separate and traceable.
Supported
ISA 230
Working paper assembly and retention
Evidence records, review decisions, and exception reasons are exportable as structured data (CSV / JSON) for inclusion in audit working papers.
Supported
ISA 500
Sufficiency and appropriateness of audit evidence
AI confidence scores and risk signals help reviewers assess evidence quality. Low-confidence extractions are flagged — the platform does not present uncertain data as reliable without human confirmation.
Supported
ISA 500
Source document traceability
Original receipt images are retained alongside extracted fields and review decisions, allowing direct reference back to the source document at any point during the audit.
Supported
ISA 320
Materiality in planning and performing an audit
Materiality thresholds can be configured per engagement. Records above the materiality threshold are automatically 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 specifically around Malaysian e-Invoicing requirements under the LHDN MyInvois framework. 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 targets the specific fields required for LHDN MyInvois compliance 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 sent to the review gate regardless of AI extraction confidence. This ensures that the records most material to LHDN compliance receive human attention before export or submission preparation.
Review Gates Before Export
No record can progress to "Export Ready" status in GetZenta without passing 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 must receive explicit human review and approval before export readiness is granted
AI does not independently grant LHDN submission readiness. That determination requires human sign-off in every case.
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 — providing a complete chain of evidence for each transaction.
🏛
LHDN MyInvois
Workflow support
⚖️
Threshold Routing
Materiality-aware
👤
Human Gate
Required before export
📋
CSV Export
With full evidence chain
🔒
Immutable Trail
Review history locked
🇲🇾
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.
📞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.
This Security Statement describes GetZenta's intended security architecture and operating principles as of the last updated date above. It is not an independent security certification, penetration test report, SOC 2 attestation, audit opinion, legal opinion, or guarantee of absolute security. No system is completely secure. Zenta Technologies takes reasonable and proportionate measures to protect user data and will update this statement when material changes are made to the security architecture.