Skip to main content

Security and confidentiality in delivery

We work in client environments with deliberate access, reviewable changes, and confidentiality by default. We describe the practices we actually use, not certifications we do not hold.

How we protect the engagement

Security is part of how technical work is scoped, delivered, reviewed, and handed over.

Least-privilege access

We request only the access needed for the agreed technical scope and review it as the scope changes.

Work in your environment

Changes are made in your repositories, accounts, and workflows so ownership and review stay with your team.

Reviewable delivery

Infrastructure and configuration changes are delivered through a visible, reviewable change process.

Confidential by default

Client names, system details, and case studies remain confidential unless disclosure is explicitly approved.

Planned handover

Access removal, documentation, and ownership transfer are considered part of delivery, not an afterthought.

Practical delivery controls

The controls below describe how we reduce unnecessary exposure while keeping engineering work effective.

Access planning

Before work starts, we agree what systems are in scope, what level of access is needed, and who approves it.

Secrets stay controlled

We use the client’s established secret-management and access mechanisms rather than copying sensitive credentials into project materials.

Changes stay auditable

Implementation through repositories, pull requests, reviews, and change history keeps technical decisions visible.

Sensitive details stay out of public material

Public examples and case studies describe patterns and outcomes without exposing client architecture or operational details.

Operational knowledge is documented

Runbooks and system notes reduce dependence on individual experts and make handover safer.

Access is removed at handover

When the scope changes or the engagement ends, access and ownership are reviewed and transferred deliberately.

Infrastructure Security

ZDT is a consulting and engineering company, not a hosted SaaS platform. Most of the systems we work on belong to our clients, so security starts with respecting their access model, review process, and confidentiality requirements.

We prefer to work through the client’s repositories, cloud accounts, CI/CD systems, and communication channels. This keeps changes visible to the people who own the system and avoids creating a parallel, opaque control plane.

At the end of a scope, we review access, document the operating context, and make the ownership transition explicit. The goal is a stronger internal capability, not a hidden dependency on ZDT.

Discuss security requirements

Security Contacts

Report a vulnerability

[email protected]

Security requirements

Discuss your constraints

Security FAQ

Common questions about our security practices.

Do you need access to production?
Only when the agreed scope requires it. We start with the least-privilege access needed for the work and prefer lower environments or read-only access where possible.
How do you work with secrets and credentials?
We use the client’s existing access and secret-management mechanisms. Credentials should remain in the systems designed to protect them, not in tickets, documentation, or public examples.
Are client names and architectures published?
No, not by default. Client work is treated as confidential, and case studies are anonymized unless the client explicitly approves disclosure.
How are changes reviewed?
Where the client workflow supports it, changes are made through repositories and pull requests with review, history, and rollback awareness.
What happens in case of a security incident?
We follow the client’s incident and escalation process for work performed in their environment, communicate promptly through the agreed channel, and preserve the relevant context for investigation.
Can you complete a security questionnaire?
We can discuss the requirements and provide information about our delivery and access practices. Any questionnaire response should reflect the actual scope and controls of the engagement.

Need more information?

Our security team is happy to discuss your specific requirements and provide additional documentation.

Discuss your situation