Security and delivery
Internal software deserves boring reliability.
You are considering giving an outside company access to the systems that run your business. This page is the honest version of what that involves — what we do, what we do not do, and what we are not certified for.
Your systems remain yours.
- You keep ownership of your data.
- You keep ownership of the custom code built for you.
- Access is documented and revocable.
- Production changes are controlled.
- Critical workflows can include human approval.
- Systems have logging and monitoring.
- Changes are version controlled.
- Rollback procedures are established where applicable.
- We document what we build.
- You are not locked into DevnTech.
If you stop working with us, your business shouldn’t stop working.
Internal software deserves boring reliability.
Nothing on this list is exciting. All of it is the difference between an automation you can leave running and one somebody has to watch.
- Controlled production access
- Version control on everything we ship
- Logging on every automated decision
- Monitoring and error alerts
- Human approvals where a wrong call is expensive
- Backups where we are responsible for data
- A documented rollback strategy
- Least-privilege permissions
- Client-owned accounts wherever possible
- Written documentation as a deliverable
- Clean offboarding, on request, at any time
In detail
How we actually work
Send this page to whoever asks the security questions at your company. If something here does not meet your requirements, tell us early and we will tell you honestly whether we can meet it.
Data handling
We work with the minimum data needed to build and verify the system. Where a workflow can be built against a redacted or sampled extract, that is what we ask for.
- Production data is used in production. Development and testing use sampled or synthetic data wherever the workflow allows.
- We do not copy client data onto personal machines outside of the agreed development environment.
- Data we hold for a project is deleted on request, and at the end of an engagement by default.
Employee access
Access is granted per person, per system, for the duration of the work — not to "DevnTech" as a blanket.
- Every person with access is named in writing, and you can ask for the current list at any time.
- Access is removed when someone rolls off the project, not at the end of the engagement.
- We prefer named accounts in your own identity provider over shared credentials.
Credentials and secrets
Credentials live in a secrets manager, never in code, tickets, spreadsheets or chat.
- API keys and service credentials are stored in the platform’s secret store or a password manager.
- Secrets are scoped to the narrowest permission that makes the workflow function.
- Where you can issue us a dedicated service account, we ask for one so it can be revoked independently.
Environments
Development, staging and production are separated, and production changes are deliberate.
- Changes reach production through a repeatable pipeline, not by hand.
- A rollback path exists before a workflow goes live.
- Where a mistake would be expensive, the workflow requires a human approval step.
AI providers and your data
We tell you exactly which model provider processes which part of your workflow, before it is built.
- We use enterprise or API tiers configured so your content is not used to train the provider’s models.
- Where data cannot leave your environment, we say so up front and design around it, including self-hosted models.
- The provider, the data sent, and the retention setting are written into the project documentation.
Ownership and IP
Custom code and configuration built for you belongs to you.
- Code is delivered into your repositories, or transferred at the end of the engagement.
- Documentation is part of the deliverable, not an extra.
- Third-party components are listed so you know what you are running.
Incident management
When something breaks in a system we operate, you hear it from us first.
- Monitoring alerts us before the business notices, wherever the workflow makes that possible.
- You get told what failed, what the impact was and what we changed so it does not happen again.
- Failed transactions are queued or routed to a person rather than silently dropped.
Offboarding
Leaving should be boring.
- Documentation, credentials and repositories are handed over.
- Our access is revoked and we confirm it in writing.
- The system keeps running on infrastructure you control.
NDAs and subprocessors
We sign your NDA before you send us anything sensitive, and we tell you who else is involved.
- Work is delivered by the DevnTech team. We will tell you if any part of it is subcontracted.
- The infrastructure and model providers we would use on your project are named during scoping.
On certifications, plainly
DevnTech is not SOC 2 or ISO 27001 certified, and we will not claim otherwise. What we can do is document our practices, work inside your security requirements, sign your NDA and DPA, and give your IT team a named contact. If a certification is a hard requirement for your procurement process, tell us early and we will tell you honestly whether we can meet it.
We put this on the page rather than waiting to be asked because claiming a certification we do not hold is the fastest way to lose an operations buyer, and because the security questionnaire always arrives eventually. Better it arrives after you already know the answer.
Security questions? info@devntech.com — a person answers, not a form.
Bring your security requirements to the first call.
Tell us what your environment demands and we will tell you honestly whether we can work inside it — before either of us spends time on scoping.
- For businesses with $5M to $30M in revenue
- No long-term commitment
- Start with one workflow
- Keep ownership of everything we build