Skip to content
Deploint

Security

Security, engineered into every layer.

The practices Deploint applies to the systems we build and to the way we run engagements. Security is designed in with the architecture, enforced by the delivery pipeline and kept working in operation.

Talk to an EngineerReport a security issue

Defense in depth

Outer to core

  1. 01Monitoring & response

    • Audit logs
    • Detection
    • Recovery

    1. 02Cloud & infrastructure

      • Landing zones
      • Segmentation
      • Hardening

      1. 03Identity & access

        • SSO
        • MFA
        • Least privilege

        1. 04Application

          • Secure SDLC
          • AppSec testing

          1. 05Data

            • Encryption
            • Secrets
            • Keys

Each layer assumes the one outside it can fail

01Build

Designed in, from the first decision.

Security requirements are set alongside the architecture and enforced by the delivery pipeline, so they hold for every change.
  • 01Build

    Security by Design

    Security requirements are set with the architecture, not after it.

    • Threat modeling during architecture
    • Data classification and data-flow diagrams
    • Security requirements in acceptance criteria
    • Architecture decisions reviewed for security impact
  • 02Build

    Secure SDLC

    Every change follows the same reviewed, automated path to production.

    • Peer review required to merge
    • Static analysis, dependency and secret scanning in CI
    • Signed build artifacts and SBOMs
    • Protected branches and environments
  • 03Build

    Application Security

    Applications are built to resist common classes of attack.

    • Validation and encoding at every trust boundary
    • OWASP ASVS as a verification reference
    • Security headers and strict content policies
    • Abuse controls: rate limits, size limits, bot traps

02Protect

Controls at every layer.

Identity, access, encryption and infrastructure controls are layered, so no single failure exposes the system.
  • 04Protect

    Identity

    Every person, service and agent has a distinct, verifiable identity.

    • Centralized identity through OIDC or SAML
    • Phishing-resistant MFA for privileged access
    • Workload identity instead of shared keys
    • Separate, scoped identities for AI agents
  • 05Protect

    Access Control

    Access is least-privilege by default, time-bound and reviewed.

    • Role- and attribute-based access control
    • Policy as code for authorization decisions
    • Just-in-time elevation for administrative access
    • Periodic access reviews and automatic expiry
  • 06Protect

    Encryption

    Data is encrypted in transit and at rest, with keys under explicit control.

    • TLS for all traffic, TLS 1.3 where supported
    • Encryption at rest with managed or HSM-backed keys
    • Key rotation and separation of duties
    • Field-level encryption where sensitivity warrants it
  • 07Protect

    Secrets Management

    Secrets never live in code, images, tickets or chat.

    • Central secret stores such as Vault or cloud secret managers
    • Short-lived, dynamically issued credentials
    • Automated rotation and revocation
    • Secret scanning before commit and in CI
  • 08Protect

    Cloud Security

    Cloud environments start from guarded, policy-controlled landing zones.

    • Account separation by environment and workload
    • Organization-level guardrails defined as code
    • Private networking for data and control planes
    • Continuous configuration and posture checks
  • 09Protect

    Infrastructure Security

    Infrastructure is reproducible, hardened and kept current.

    • Infrastructure as code with reviewed changes
    • Minimal, hardened base images
    • Network segmentation and default-deny policies
    • Automated patching and image rebuilds

03Operate

Detect, respond, recover.

Systems are built to make misuse visible, incidents manageable and recovery predictable.
  • 10Operate

    Monitoring

    Systems produce the telemetry needed to detect misuse as well as failure.

    • Centralized, tamper-evident audit logs
    • Security alerts routed to accountable owners
    • Anomaly detection on access and usage patterns
    • Model and agent activity traced end to end
  • 11Operate

    Incident Response

    Teams know what to do before an incident happens.

    • Runbooks for likely incident types
    • Defined severity levels and escalation paths
    • Evidence preservation and timeline capture
    • Blameless post-incident reviews with tracked actions
  • 12Operate

    Business Continuity

    Systems fail safely and recover predictably.

    • Recovery point and time objectives agreed per system
    • Backups verified by restoring them
    • Multi-zone or multi-region designs where justified
    • Environments rebuildable from code

04Engagements

How we operate engagements.

The same discipline applies to how our team works inside client environments, from the first access request to handover.
  1. 01

    Client-controlled access

    We work in client environments through accounts the client issues, scopes and can revoke at any time.

  2. 02

    Least privilege for our team

    Engineers receive only the access their workstream needs, and it is removed when the work ends.

  3. 03

    Data minimization

    We avoid copying production data. Where test data is needed, we prefer synthetic or masked data.

  4. 04

    Strong authentication

    Multi-factor authentication on every account used for client work, with phishing-resistant methods preferred.

  5. 05

    Clean handover

    Credentials, documentation and runbooks are handed over at the end of an engagement, and our access is removed.

05Compliance

Engineering that supports your compliance program.

This page describes engineering practice. It is not a statement of certification, audit or attestation status.
Cybersecurity capability

Control support

Engineering references

Where a client operates under a framework such as ISO/IEC 27001, SOC 2 or NIST SP 800-53, we engineer the systems we deliver to support that client's control requirements: mapping controls to architecture, producing the technical evidence auditors ask for, and keeping it reproducible from code and pipelines.

Frameworks we engineer against

  • NIST Cybersecurity Framework
  • NIST SP 800-53
  • ISO/IEC 27001
  • SOC 2
  • OWASP ASVS
  • CIS Benchmarks

Named as engineering references only. Naming a framework does not imply certification.

06Responsible disclosure

Found a security issue?

If you believe you have found a vulnerability in a Deploint website or system, please tell us. We appreciate good-faith reports and will work with you to understand and resolve the issue.
Report a security issue
  1. 01

    Report it through our contact page

    Use the contact page and choose “Security report” as the inquiry type so it reaches the right engineers.

  2. 02

    Keep the first message brief

    Describe the affected system and the type of issue. Don't include exploit code or sensitive data; we'll arrange a secure channel for details.

  3. 03

    Test responsibly

    Don't access, modify or delete data that isn't yours, degrade service for others, or use social engineering or physical attacks.

  4. 04

    Allow time to fix

    Give us reasonable time to investigate and remediate before any public disclosure.

Start an engineering conversation

Building a system that has to be secure?

Bring us the architecture and the threat landscape. We'll help design controls that hold up in production.

Talk to an EngineerCybersecurity capability