Security & Trust Centre

Security you can check, not badges you can't

This page lists what BuildCore actually does to protect the project record — how people sign in, what they can see, what is logged, how organisations are kept apart and where the AI runs — so your IT and procurement teams can verify it.

Signing in

Passwords hashed with PBKDF2-SHA256 — 100,000 iterations and a unique salt per password
Accounts lock after repeated failed sign-ins (5 attempts, 15 minutes by default, configurable)
Signed access tokens that expire, and refresh tokens that rotate on every use and are revoked on sign-out or password change
Password reset never reveals whether an account exists
Sign-in and password-reset requests are rate-limited

What people can see and do

More than 200 permissions, checked on the server for every request — not in the browser
Custom roles per organisation
Access restricted by module and by project
Individual documents can be allowed or denied per user or role, with an expiry date
User accounts provisioned and deactivated through SCIM 2.0 — deactivated, never deleted

Audit

Audit records capture the user, the action, the time, the IP address and before-and-after values
Records are hash-chained per organisation, so tampering is detectable, with a built-in integrity check
The application never edits or deletes audit records; older entries are archived, not destroyed

Keeping organisations apart

Every query is scoped to the organisation, and SQL Server row-level security filters tenant data as a second layer
Uploaded files are stored per organisation and fingerprinted with SHA-256
File types and sizes are restricted; document revisions are checked against their real file type

AI, under your control

AI can run on a local model on your own network
External AI providers stay off until they are enabled for your organisation, with an optional list of approved providers
Every AI prompt and response is logged
HR AI runs only on a local model, never falls back to a cloud provider, and masks identifiers such as Aadhaar, PAN, bank details, salary and medical details before processing

Deployment and operations

Cloud, private cloud or your own servers — .NET 8 and SQL Server, on Windows (IIS) or Linux
The interface's libraries ship with the application rather than loading from the internet
Health-check endpoints and structured logs for your monitoring
Outbound webhooks are signed (HMAC), so receiving systems can verify them
Most registers export to Excel or CSV, and HR data can be exported in full

Straight answers

Security questions buyers ask

Not today, and we won't imply otherwise. This page describes controls you can verify, we'll answer your security questionnaire in writing, and on your own servers your organisation's own controls and certifications apply.

Yes. It runs on .NET 8 and SQL Server on Windows or Linux, behind your firewall. Email needs your own mail server, AI can use a local model, and licensing can use an offline licence file.

Only if you choose it. External AI providers stay off until they're enabled for your organisation; otherwise AI runs on a local model on your network, or not at all. HR AI never leaves your network.

Each record is chained to the one before it with a SHA-256 hash, per organisation, so an altered or removed record breaks the chain — and BuildCore includes a check that recomputes it. The application itself never edits or deletes audit records.

Every query is scoped to the signed-in organisation, and SQL Server row-level security filters tenant data as a second layer. Files are stored in a separate area per organisation.

Due diligence

Send us your security questionnaire

Tell us about your deployment and access requirements, and we'll answer in writing — including what BuildCore doesn't do yet.