Skip to main content
EN
Home / Security

Security

How we build and run secure systems, and how to report a security problem to us.

Security principles

Eight rules we follow on every project.

These apply to every product we release and every system we run for a client.

01

Security by Design

We look for risks while designing the system, before any code is written.

02

Least Privilege

Each person, service and access token gets only the permissions it needs.

03

Encryption

TLS for all connections, encrypted storage where the platform supports it, and encrypted backups.

04

Audit Logging

Administrative and security-related actions are recorded: who did what, to what, and when.

05

Multi-Factor Authentication

Administrator accounts require a second factor in addition to the password.

06

Vulnerability Management

Dependencies are scanned continuously, and findings are prioritised by their real impact.

07

Regular Security Review

Architecture, permissions and access lists are reviewed on a fixed schedule.

08

Secure SDLC

Code review, automated tests, secret scanning and signed packages are required before every release.

In brief: we think about security from the first design discussion, not only when a project is about to ship. This page explains how we build and run our systems, and how to report a security problem to us.

Last updated: 31 July 2026

How we build

  • We look for risks before writing code. For every important feature we ask three questions first: what does it expose, who can reach it, and what happens if one safeguard fails.
  • Every change is reviewed and tested. A colleague reviews each change, and it must pass automated tests, a dependency scan and a check for leaked secrets before it can be released.
  • Customers and extensions are kept apart. Each customer's data and each website are separated at the database level. Extension code runs in a sandbox and can only use the permissions it has declared.
  • Installed packages are signed. Every package our platform installs carries a digital signature, which is checked before the package runs. This ensures the code that runs is exactly the code we published.
  • Passwords and keys are never in the source code. Credentials are kept in a secret store, each one limited to a single environment. We change them whenever someone's access changes.

How we operate

  • Encryption. All traffic uses TLS. Stored data is encrypted where the platform supports it, and backups are always encrypted.
  • Access control. Each administrator has only the access their job needs, under their own account, protected by multi-factor authentication. We review access when someone changes role and remove it when they leave.
  • Audit logs. Administrative and security-related actions are logged with who did it, what was affected and when. If something goes wrong, we can trace exactly what happened.
  • Backups we have actually tested. Backups run automatically, and we restore them regularly to make sure they work.
  • Monitoring and incident response. We monitor availability, errors and security signals. When an incident happens, we follow a set process: detect, contain, recover, then write up what we learned.
  • Updates. We update dependencies and infrastructure on a regular schedule, and sooner when a vulnerability requires it.

Your data and AI

Customer data belongs to the customer. We do not sell it, and we do not use customer content to train public AI models without explicit agreement. When a product uses an AI model, its documentation and contract state what data is sent to the model, how long it is kept and where a person reviews the result.

Reporting a vulnerability

If you find a security problem in a Z-SOFT website, product or service, please tell us before telling anyone else.

How to report

Email security@z-soft.com.vn with enough detail for us to reproduce the problem: the affected URL or component, the steps you took, what you were able to see or do, and a proof of concept if you have one. You can write in English, Vietnamese or Japanese.

What we ask of you

  • Only go as far as needed to show that the problem exists.
  • Do not view, change, delete or keep data that is not yours. Once you can show that access is possible, stop and tell us what you saw.
  • Do not run denial-of-service tests, send spam, or use social engineering or physical attacks against our staff or suppliers.
  • Give us a reasonable amount of time to fix the problem before you publish anything, and agree the timing with us.
  • Follow the law while you do your research.

What we promise

  1. We confirm that we received your report within 72 hours.
  2. We assess the report, tell you what we found, and keep you updated while we fix it.
  3. We do not take legal action against researchers who follow the rules above and act in good faith.
  4. When the fix is released, we credit you by name if you would like.

Usually out of scope

Reports that come only from an automated scanner with no demonstrated impact; missing security headers or hardening settings without a working attack; problems that require an already compromised device, a modified browser or an attacker who is physically present; and vulnerabilities in third-party services we do not run. If you can show real impact in any of these cases, send the report anyway.

Contact

Security reports: security@z-soft.com.vn. Everything else: contact@z-soft.com.vn.

Responsible disclosure

Found a security problem? Let us know.

Send the details to security@z-soft.com.vn. We confirm every report within 72 hours and keep you updated until it is fixed.

Email the security team
PARTNER WITH Z-SOFT

Every technology decision made today will have an impact for years to come.

Talk with the Z-SOFT team to assess your current state, define your goals and choose an architecture aligned with your business's growth direction.

Book a consultation