Where your data lives, and who can see it

Your project data, contract documents and uploaded files are stored in Australia, in a managed Postgres database in the Sydney region.

The compute that touches those rows is pinned to Sydney too. That is a separate decision from where the database sits, and it is the one most platforms get wrong: a global hosting default runs your API requests in the United States and pulls Australian rows across the Pacific to serve them. Ours is pinned in configuration, and a test in the build fails if anyone removes the pin.

Not everything stays here, and the exceptions are named rather than buried. Contract text sent for review, extraction or letter drafting is processed by AI providers in the United States, and error monitoring, email delivery and website enquiries are handled by providers offshore as well. The privacy policy lists all 9 subprocessors, what each one receives and where it processes, and an automated test fails the build when that list and the code disagree. AI features can be turned off for your organisation.

Nobody outside your organisation, and the database is what enforces that rather than the application.

Every table holding customer data carries row-level security, so a query for another organisation's rows returns nothing regardless of what the front end asks for. Your internal labour and plant rates, and everything computed from them, are locked to your organisation at that layer: the parties above you in the contract chain and the contractors below you never see them, and a bug in a screen cannot leak what the database has already refused.

Where a write needs more than a policy can express, it goes through a database function that checks the caller's capability before it does anything. That function body is the authorization layer, and adding a new one is a documented procedure rather than a judgement call.

Access is capability-based rather than role-based: a person holds a set of specific permissions (approve a docket, certify a claim, see internal cost) rather than a job title that implies them.

You set them. Clone one of the built-in bundles, adjust it to how your organisation works, and re-grade a bundle to see how many people it affects before you commit; the database checks that number rather than the screen. A site supervisor who should see the program and the open items, but not the margin, is a configuration rather than a request to us.

The same capability that hides a screen is checked again on the server, so an unauthorised request fails whether it came from the app or from somewhere else.

Actions are written to an audit trail that records who acted, what they did, which record and which project it touched, the address the request came from, and when. It is scoped to your organisation like everything else, so it is your record to read.

The commercial trail is separate from that and more useful in a dispute: every figure traces to the docket, variation or certificate that produced it, and a substantiation packet exports the lot for a claim period on demand.

Data is encrypted in transit and at rest. Sessions are cookie-based and server-verified; the browser never holds a long-lived key to your data.

tectm holds no security certification today: no SOC 2, no ISO 27001. When that changes it will be stated here with a date and an auditor, and not before.

There is no published uptime commitment, and single sign-on is not available yet. If your procurement process needs either, say so in the enquiry: it is a roadmap conversation rather than a feature we are hiding.

We would rather this section existed than have you find out by asking.