How we hold your systems and your data.

How client data is handled

Our default position is that we do not take custody of client data. We work inside your systems, on your tenancy, under accounts you issue and can revoke. Where a build genuinely requires data to leave your environment, we agree in writing what data, for what purpose, where it will sit and when it will be destroyed, before any of it moves.

For development and testing we ask for synthetic or masked data. Where a defect can only be reproduced on production data, we agree a narrow, time limited extract, hold it in the environment the client nominates, and delete it when the defect is closed.

• Minimisation. We request the narrowest dataset that makes the work possible, and we push back on blanket exports.
• Segregation. Client material is kept in per client workspaces, repositories and drives. It is never pooled across clients or reused as a template.
• Transfer. Files move through the client's own systems or an encrypted channel the client approves. We do not accept production data by email or consumer file sharing.
• Return and destruction. At the end of an engagement we return or destroy client material on request and confirm it in writing.

Personal information handled through our own website and enquiry channels is covered separately in our privacy policy.

Access control and least privilege

Access follows the engagement, not the person's seniority. Someone joining an engagement receives the narrowest permission set that lets them do the task, and that access is removed when they leave the engagement rather than when they leave the firm.

• Named accounts. Every person works under an individually named account. We do not use shared logins, and we ask clients not to issue them.
• Multi-factor authentication. Enforced on our identity provider, our source control and our cloud consoles, and requested on every client system that supports it.
• Role separation. Production access is granted to the smallest group that can support the platform. Developers do not hold standing production administrator rights by default.
• Reviews. We review who holds what on each engagement at least quarterly and whenever someone changes role, and we give clients the list on request.
• Offboarding. When a person leaves the firm, accounts are disabled the same day and client administrators are notified so they can revoke their own grants.

Where a client operates its own privileged access process, we work inside it. We will use just in time elevation, break glass accounts and approval workflows where you provide them.

Secure development practice

Security is part of the definition of done, not a stage at the end. The same review gate applies whether the change is a Salesforce configuration, an Apex class or a language model prompt chain.

• Peer review. Every change is reviewed by an engineer who did not write it before it can be merged.
• Automated checks. Static analysis, dependency vulnerability scanning and the test suite run on the pipeline, and a failing check blocks the merge.
• Dependencies. We keep third party libraries current, prefer well maintained packages, and treat a known vulnerability in a production dependency as a defect with a due date.
• Design review. Authentication, authorisation, data exposure and integration boundaries are settled at design time and written down, so the decision can be audited later.
• AI specific controls. For language model work we define what may be sent to a model, restrict tool and data access to what the task needs, keep a record of prompts and outputs where the client requires traceability, and test for prompt injection and data leakage before release.

We do not use client code or client data to train models, and we disable training on submitted content with the model providers we use.

Code and secrets management

Source code lives in access controlled repositories, one set per client, with branch protection on the mainline and history retained for audit. Where the client owns the repository, we work in it rather than taking a copy.

• No secrets in source. Credentials, keys and tokens are held in the platform's secret store or the client's vault, injected at deploy time and never committed.
• Detection. Secret scanning runs against the repository, and a detected credential is revoked and rotated before the fix is considered complete.
• Rotation. Keys we hold for a client are rotated on a schedule agreed with the client, and immediately when a person with access leaves the engagement.
• Local copies. Engineers work on encrypted machines, and repositories are not copied to personal devices or personal accounts.

Intellectual property in work we deliver transfers to the client under the services agreement. Handover includes the repository, the pipeline definition and the documentation needed to run it without us.

Environment separation

Development, testing and production are separate environments with separate credentials. A change moves forward through them in one direction, and nothing reaches production without passing the stage before it.

• Promotion path. Changes are deployed from source control through an automated pipeline, not by hand, so what was tested is what ships.
• Sandboxes. On Salesforce we work in developer and full copy sandboxes, refresh them under the client's data handling rules, and mask or scramble personal data where a full copy is used.
• Release control. Production releases follow the client's change process, run to a schedule, and carry a tested rollback path.
• Production access. Production work is done for a stated reason, by a named person, with the client's knowledge.

Where a client has no release process of its own, we set one up as part of the engagement rather than working around the gap.

Hosting, data residency and inference region

Systems we build are hosted in the client's own cloud accounts wherever that is possible, so the client holds the tenancy, the billing relationship and the ability to revoke our access. Where we host on a client's behalf, we use established cloud providers and name the region in the agreement.

• Region selection. Australian workloads are deployed to Australian regions by default. Where a client requires data to remain onshore, that becomes a written constraint on the architecture, not a preference.
• In-region inference. For AI work we can run inference in a required region, including Australian regions, using the model providers that offer it. We confirm the region, the provider and the data retention terms before the design is signed off.
• Encryption. Data is encrypted in transit with current TLS and at rest using the platform's managed encryption. Keys are held in the platform key service, in the client's tenancy where the client hosts.
• Sub-processors. We will name every third party service a system depends on, what it processes and where it runs, before go-live and on request afterwards.
• Cross-border access. Our delivery team includes engineers in Sri Lanka. Where a client requires access to be restricted to Australia, we staff the engagement that way and enforce it through account provisioning.

Our own corporate systems run on a major cloud productivity platform with multi-factor authentication enforced, and our website is served over HTTPS with transport security and a restrictive content security policy.

Confidentiality and non-disclosure

We sign client non-disclosure agreements, and we will sign yours rather than insisting on ours. Confidentiality obligations flow to every person on the engagement through their employment or contracting terms, and they survive the end of the engagement.

• Named references. We do not name a client, publish a logo or describe an engagement publicly without written approval. Case studies on this site are anonymised until that approval exists.
• No cross-use. A client's design, data or configuration is not reused on another engagement. General engineering knowledge is ours to carry forward; your specifics are not.
• Subcontractors. We do not place a subcontractor on an engagement without the client's agreement, and anyone who works on it is bound by the same terms we are.

Where an engagement requires background checks, police checks or a security clearance for the people working on it, tell us during scoping and we will meet the requirement or decline the work.

Device and endpoint posture

Client work is done on company managed machines. We treat the endpoint as part of the security boundary, because for a firm of our size it is.

• Full disk encryption. Enforced on every machine used for client work.
• Screen lock and strong authentication. Automatic lock on idle, and multi-factor authentication on the accounts that reach client systems.
• Patching. Operating system and browser updates are applied promptly, and endpoint protection is enabled and kept current.
• Password management. Credentials are held in a managed password manager. Sharing credentials outside it is not permitted.
• Loss and theft. A lost or stolen device is reported immediately, sessions are revoked, and affected clients are told the same day.

Where a client issues its own hardware or requires a virtual desktop, we use it and leave our own machines out of the path entirely.

Incident response and reporting an issue

A security incident is handled as the highest priority work in the firm. Our response is deliberately simple, because a small team needs a process it will actually follow under pressure.

• Triage. The person who finds or receives the report escalates to the engagement's technical lead immediately. Severity and blast radius are assessed first.
• Contain. Revoke credentials, close the access path, preserve logs and evidence before cleaning anything up.
• Notify. Affected clients are contacted without delay, with what we know, what we do not yet know and what we are doing. We do not wait for a complete picture before telling you.
• Remediate and review. Fix, verify, then a written review covering cause, timeline and the control change that prevents a repeat.
• Regulatory obligations. Where an incident involves personal information, we support the client's assessment and notification under the Notifiable Data Breaches scheme, and meet our own obligations under the Privacy Act 1988 (Cth).

Report a security issue

If you believe you have found a vulnerability in something we build, operate or publish, tell us. Include what you found, where, and how to reproduce it.

We acknowledge a report within one business day and give you a substantive response within five. We will not pursue a researcher who reports in good faith, works only on their own data, avoids privacy violations and service disruption, and gives us reasonable time to fix the issue before disclosing it.

Business continuity

Continuity risk for a firm our size is concentration risk: one person holding knowledge nobody else has. We manage it deliberately rather than assuming it away.

• No single point of knowledge. Every engagement has at least two people who can work on it, and the documentation to bring a third up to speed.
• Client owned assets. Code, pipelines, environments and documentation sit in systems the client can access without us, so nothing is trapped behind our accounts.
• Two delivery locations. Work runs from Melbourne and Sri Lanka, so a local disruption in one does not stop an engagement.
• Backups and recovery. For systems we host, backups are configured with a stated recovery point and recovery time objective, and restores are tested rather than assumed.
• Exit. Every engagement can be handed over. We will write the handover pack and run the transition rather than making an exit expensive.

We hold the business insurances expected of an Australian technology supplier, and we will provide current certificates of currency during vendor onboarding.