Security and data

A practice, not a certificate

This page is written so that an IT lead, a security function or a business owner can make a decision — not so that anyone feels reassured. Below: where data sits, who can reach it, how credentials are handled, who owns the code and the data, what happens when an engagement ends, and how a security question gets answered mid-project.

The distinction to hold while reading

A certificate such as ISO/IEC 27001 or SOC 2 means a third party has examined an organisation's management system and evidence against a standard and attested to it for a period. Gomusoft has none.

A practice is what we actually do and what you can verify yourself during the engagement — open the access list on your own repository and cloud account, ask for the access log, scan the system with your own tools. A verifiable practice is worth more than a claim, but it does not substitute for a certificate in an auditor's eyes. If your organisation requires certification, Gomusoft does not qualify.

Personal data and PDPA

In most engagements your organisation is the data controller and we act as a processor on your instructions. Purpose, scope and duration of access are set by you and recorded in writing. Draft

We will sign a personal-data processing agreement on your organisation's template. Gomusoft has no counsel-reviewed template of its own, so we won't offer you one. Draft

Real personal data does not leave your environment for development or testing; development runs on synthetic or de-identified data. Where real data is genuinely required, it is approved case by case and recorded.

Your data is not used to train or tune any AI model, ours or a provider's. If the system must call an external AI service, the architecture document states exactly what leaves, where it goes, and whether an option exists that sends nothing.

Only what is necessary and agreed is held. Every copy we hold during the engagement is listed and has an end date.

If an incident may affect personal data, we notify your named contact as soon as we know, with what is known and what is not yet known. Notifying the regulator is the controller's duty — yours — and we supply the technical detail it needs. Draft

Where data sits, and who can reach it

• Option 1 — on your own infrastructure. Data never leaves your boundary. This is the option for organisations with a firm data-residency requirement.
• Option 2 — cloud, in your organisation's own account, in a region you choose including a Thailand region. The account and the billing are yours; we are a user granted access. This is what we recommend by default.
• Option 3 — in a Gomusoft environment, for short prototypes only, agreed in advance and with synthetic data only. At the end of the prototype the environment is destroyed and that is confirmed in writing.

Who can reach a system depends on what's agreed with you for that system — us, plus anyone agreed and named in that agreement, and no one else. Nobody you haven't been told about receives access. Credentials always live in your own accounts. Everyone granted access sits under the same confidentiality agreement, and the access list lives in your own account — you can inspect it, or revoke any of it, at any time without going through us.

Every external service the system calls — cloud, email delivery, an AI service — is listed by name in the architecture document, with what reaches it and why. No new processor is added without telling you first.

What self-hosting does and does not give you

Self-hosting does not automatically mean more secure. It means the burden moves to you.

The way we decide is to ask whether someone in the organisation owns patching and backups for this machine as part of their standing job. If the answer is no, we'll propose something else — even when self-hosting looks safer on paper.

Access control and credential handling

• Individual accounts, never a shared login, so that logs identify a person.
• Least privilege for the task at hand. Administrative rights are requested when needed and returned when the task ends, not held permanently.
• Credentials live in your organisation's secret store, never in chat, email or a generally shared document. If you don't have one yet, setting it up is the project's first task.
• Multi-factor authentication on every account that supports it.
• A record of who was granted what, when, approved by whom, and when it was revoked — delivered with the documentation each milestone.
• No secrets in code, and none in the repository history.
• If your organisation has its own access policy, we follow yours rather than ours — and where yours is stricter than the above, we adopt it.
• The machine we work on has full-disk encryption and screen lock, and we don't keep copies of your real data on it beyond what the task in hand requires.

Ownership

• The source code written for you belongs to your organisation. The repository sits in your account from day one — not transferred at handover.
• All data belongs to your organisation. We claim no rights over it, don't reuse it, and don't aggregate it into statistics or another product.
• Cloud accounts, domains and third-party service accounts are in your name and paid for by you.
• Code written specifically for your business is not reused for another client. Generic components and open-source libraries are listed in the documentation with their licence terms, so it's clear what is exclusively yours and what isn't.
• We don't design architectures or data formats that oblige you to come back to us, and we're happy for that to be a contract clause.

When an engagement ends

• Our access and that of anyone we introduced is revoked within the agreed window, and you can verify it yourself from your own account.
• Copies of data held outside your systems are deleted, and we confirm in writing what was deleted and when.
• A final documentation set is delivered: architecture, deploy and rollback procedures, the credential register with owners, the reasoning behind significant technical decisions, and the open-items list.
• We attend handover sessions with whoever takes over, regardless of how the contract ended or who they are.
• Confidentiality obligations continue for the term stated in the contract.

If a security question comes up during a project

• We answer it ourselves, in writing, through IT or the named contact — not verbally in a meeting and then nowhere.
• If we don't know, we say we don't know, and state how and by when we'll find out. If it needs a specialist or an external assessor, we say so and help scope the assessment.
• If your security function scans or reviews and finds something, we remediate on the severity schedule agreed in advance and report the fix in writing.
• If a security requirement changes the project's cost or timeline, we say so when we learn it, not at handover.
• If you ask us to do something we consider unacceptably risky, we object in writing first, then follow the system owner's decision — with our objection on the record.