Trust
Security, and what we do with your data.
We are asking to be given access to your cloud accounts, your repositories and, in some engagements, your production data. This page is the answer to what happens then. It is written to be read by your security team, so it is specific and it includes the parts we do not have.
Start here
What we do not have.
Security pages usually open with the certifications. This one opens with the gaps, because that is the part your security team will find anyway and it is cheaper for both of us if they find it here.
Conseiltek does not hold a SOC 2 report of its own
We have no SOC 2 Type I or Type II attestation and no ISO 27001 certificate as a firm. We will not imply otherwise in a procurement questionnaire, and if a control on your vendor assessment requires one, the honest answer is that we fail that control today.
What we can offer instead: the systems we build are designed against SOC 2 and ISO 27001 control expectations and we map them explicitly for clients who need it, the work runs inside your accounts and under your controls rather than ours, and we will answer any questionnaire in full and in writing. If your policy requires an attested supplier regardless of engagement shape, that is a legitimate reason not to work with us.
Client data during an engagement
We work in your cloud account, not ours.
The default and strongly preferred arrangement is that every environment we build lives in your AWS account or your Azure subscription, under your organisation policies, your logging, your key management and your identity provider. We hold named federated identities in your tenant with scoped roles. There is no Conseiltek-hosted copy of your system, because there is no Conseiltek-hosted anything.
This is not only a security position. It is why the cost models on this site are cloud bills rather than platform fees, and it is what makes the handover at the end of an engagement a change of access rather than a migration.
Production data
We do not take production data into our own environment. If a piece of work genuinely requires it — a migration reconciliation, a defect that only reproduces on real data — it happens under a written agreement that names the dataset, the purpose, the storage location, the retention period and the deletion date, and the data is masked or synthesised wherever the work permits it.
In practice that agreement is rarely needed, because the debugging happens in your non-production environment with a masked extract that never leaves your account. When it is needed, it is a signed document, not an email thread.
Data in migrations
Extraction from an incumbent SaaS product runs inside your account, using credentials you issue and can revoke, writing to storage you own. Reconciliation reports contain counts and checksums rather than records. Extracts are deleted on a schedule agreed in the migration plan, and the deletion is evidenced.
Laptops and endpoints
Our engineers work on managed, full-disk-encrypted machines with screen lock, automatic patching and hardware-backed keys for authentication. Client source code is cloned only where the client permits it; several clients require work inside a VDI or a cloud development environment they control, and we support that without argument. Client credentials are never stored in plain files or personal password managers.
Source code
You own what we write for you.
Work produced for a client under a statement of work is assigned to the client. It lives in your repository from the first commit, not in ours with a handover at the end. There is no escrow arrangement to negotiate, because there is nothing to escrow.
The reference applications in Techtons, our public library, are a separate thing. They are ours, published under Apache-2.0, and they are what an engagement usually starts from. That licence is permissive and irrevocable for the versions you receive: if we stopped trading tomorrow, your fork keeps working and you keep the right to modify and redistribute it.
Two consequences worth stating plainly. First, generic improvements we make to a Techtons application while working with you may be contributed back to that public repository — never anything client-specific, never your configuration, your data, your schema extensions or your business logic, and never without it being obvious in the pull request. Second, we do not carry your code into another client's engagement. What travels between engagements is the engineers and the public repositories, which is the entire point of publishing them.
Third-party licences in anything we ship are inventoried, and we produce a software bill of materials on request. We avoid copyleft licences in client deliverables unless you ask for them.
Access and offboarding
Least privilege, named identities, and a leaving date in the plan.
Access is the control that matters most in this kind of engagement, because it is the one that outlives the work if nobody manages it.
Named identities only
Every engineer has their own federated identity in your directory. No shared accounts, no shared keys, no service principal handed round the team. If your SSO cannot federate us, we use individual accounts with hardware MFA enforced.
Least privilege, with an expiry
Roles are scoped to the environments in scope and requested in writing. Production access is separate from non-production, granted when a specific task needs it, and time-boxed. Standing production write access is the exception and is recorded as one.
Offboarding is on the plan, not the goodwill
When an engineer rolls off, or the engagement ends, revocation is a dated task in the delivery plan with a named owner on your side. We ask you to confirm it has happened, and we chase you if you do not.
Your logs, your evidence
Because we work in your account, every action we take is in your CloudTrail or Azure activity log, under our name, and available to your auditors without asking us for anything.
AI tooling on client code
The section your security team actually wants.
We are an AI engineering firm and our engineers use AI tooling on real code every day. That is how an eight-week build is credible. It also means your source code, and sometimes your schema and your log excerpts, pass through a model provider. Pretending otherwise would be dishonest, so here are the rules we work under.
Rules that do not bend
- No client code or client data goes to any tool that trains on inputs. Commercial or enterprise plans with contractual no-training terms only — never a consumer tier, never a personal account, never a free tier that funds itself on data.
- Zero or minimal data retention is a requirement, not a preference. Where a provider offers a zero-data-retention configuration for a plan, we use it, and where it is available only under a signed agreement, we sign it before the engagement rather than during it.
- The client approves the tool list before work starts. It is part of the engagement setup, alongside access requests, and it goes in the statement of work. If you prohibit a tool, we do not use it, including where that makes us slower.
- Your prohibitions win over our defaults. Several clients allow AI assistance on their own repositories but not on anything containing customer data, or only inside their tenant. We work to that.
- Secrets, credentials, personal data and production records are never pasted into a model, by anybody, for any reason. Masked and synthetic data only.
- A human is accountable for every line. AI-assisted code goes through the same review, the same tests and the same named approver as anything else. "The model wrote it" is not a defence and does not appear in a post-incident review.
What tools, specifically
The approved list is short, versioned, and named in the statement of work. It is restricted to enterprise or business tiers of coding assistants and model APIs whose terms state that customer content is not used to train models, and whose retention can be set to zero or to a short, stated window.
The current list is supplied on request and in every proposal, rather than published here, because it changes as vendor terms change and a stale list on a website is worse than no list. Ask us for it before you sign anything and we will send it with the relevant clause from each vendor's terms quoted directly.
What we will not claim
We will not tell you that AI-assisted code is inherently safer, or that a model has been audited in any meaningful sense. We will not claim we can prove a given line was or was not model-generated. And we will not claim a no-training guarantee extends further than the vendor's own contract does — if you want that assurance, read the clause, and we will send it to you.
If your organisation prohibits AI assistance on your code entirely, say so at the start. We will staff and price the engagement accordingly. It is a real constraint with a real cost, and it is far better handled in the proposal than discovered in a code review.
Secure SDLC
How code gets from a branch to your production.
The same pipeline shape ships every reference application in Techtons, which means you can read it before you hire us.
Threat model first
Every application starts with a written threat model covering trust boundaries, authentication, tenancy and the data classes involved. It is a document in your repository, revised when the architecture changes.
Review and provenance
No direct pushes to a protected branch. Every change is reviewed by a named human, commits are signed, and the merge record is the audit trail.
Automated checks in CI
Static analysis, dependency and container scanning, secret scanning, infrastructure-as-code policy checks and licence checks. Failures block the merge rather than raising a ticket nobody reads.
Dependencies
Pinned versions, lockfiles committed, automated update pull requests, and a software bill of materials produced per release.
Secrets
Held in AWS Secrets Manager or Azure Key Vault, injected at runtime, never in environment files, never in a repository, rotated on a schedule. Secret scanning runs on history as well as on the diff.
Environments and release
Non-production is separated by account or subscription, not by tag. Infrastructure changes go through plan review. Releases are reversible, and a rollback is rehearsed before a cutover, not designed during one.
Penetration testing is scoped per engagement. Where a system we build handles regulated or personal data, we recommend an independent test before go-live and we plan the remediation window into the delivery schedule rather than after it.
Subprocessors
Who else touches anything.
Because engagements run inside your cloud account, the list of parties processing your data on our behalf is short by construction. In most engagements it is empty: your cloud provider is your subprocessor, contracted directly with you, not ours.
Where we do process anything ourselves — correspondence, project documentation, the approved AI tooling — the providers are named in the data processing agreement, with the processing purpose and region for each. We give notice before adding a subprocessor that touches client data, and your DPA can carry a right to object.
The current subprocessor list is supplied with the DPA and on request to support@conseiltek.com. It has not been published as a page here yet, and until it is, this sentence is the accurate description of the position rather than a promise of one.
Responsible disclosure
Found something. Tell us.
If you believe you have found a vulnerability in this website, in one of the reference applications in Techtons, or in a system we operate, email support@conseiltek.com. Include enough detail to reproduce it. If you would rather encrypt the report, ask for a key in a first message and we will send one.
What we commit to
- We acknowledge every report within two working days, from a human.
- We give you an initial assessment, with a severity and a plan, within five working days.
- We tell you when it is fixed, and we credit you in the commit or the release notes unless you would rather we did not.
- We will not take legal action over good-faith research that follows the rules below.
What we ask
- Do not access, modify or exfiltrate data that is not yours, and stop at the point where you have proved the issue.
- No denial of service, no social engineering of our people or our clients, no physical testing.
- Give us a reasonable window to fix it before publishing — we will agree a date with you rather than argue about one.
- Do not test client systems. They are not ours to authorise, and a report about a client system should come to us so we can route it with their consent.
We do not run a paid bounty programme. We would rather say that than imply one exists.
Security questionnaires and due diligence
Send them. We complete vendor security questionnaires in full, in writing, without marking a control as compliant when it is not, and we will get on a call with your security team rather than only exchanging spreadsheets. Where we fail a control, the response says so and explains what we do instead.
For anything relating to security, data handling or a disclosure, write to support@conseiltek.com. For everything else, including the assessment, the contact page or support@conseiltek.com.