[ Security ]
Security is built from day one, not at the end.
Dexon designs and runs software for demanding industries. This page explains, without jargon, what we actually do to protect your applications and your data: the steps, the standards and the tools. A starting point for your security teams, even before the first meeting.
- Approach
- Secure by Design · DevSecOps
- Encryption
- TLS 1.3 in transit · AES-256 at rest
- Access
- MFA · least privilege · IAM
- Continuity
- Backups · DRP / BCP
- Compliance
- GDPR
- Updated
- 2026
[ Methodology ]
Six steps, from scoping to operations.
Security is not an audit bolted on at the end of a project. It follows the software lifecycle: every step has its controls, and every control leaves a trace.
- 01
Scoping
We identify the data handled and its sensitivity, realistic threats and regulatory obligations. Security requirements go into the specifications.
- 02
Design
Secure by Design: architecture, data flows, environment segmentation and access rights are decided before the first line of code is written.
- 03
Development
Systematic code review before merge, secrets never stored in code, open-source dependencies chosen and tracked.
- 04
Integration & delivery
Secure CI/CD: automated tests, vulnerability and dependency scanning on every build, traceable and reversible deployments.
- 05
Security testing
Security tests built into acceptance testing, and penetration tests when the project's criticality warrants it, before going live.
- 06
Operations
Monitoring, alerting and logging in production. Vulnerabilities found after delivery are assessed, then fixed.
[ Technical standards ]
What we actually apply.
Simple, verifiable rules applied by default on our projects. They are refined and adapted with you during scoping, according to your context and your own policies.
- 01EncryptionTLS 1.3 for data in transit, AES-256 for data at rest.
- 02Strong authenticationMFA on administration access, development tools and cloud consoles.
- 03IAM policyNamed accounts, least privilege, rights reviewed regularly and revoked when someone leaves the project.
- 04Secrets managementKeys and passwords kept in a dedicated vault, never in code, tickets or chat.
- 05Environment segmentationDevelopment, staging and production isolated. No real production data outside production without anonymisation.
- 06Cloud hostingEstablished providers, data location chosen with you according to your constraints.
- 07Logging & traceabilityCentralised logs, sensitive actions traced: who did what, and when.
- 08Vulnerability managementMonitoring of published flaws, fixes prioritised by severity and actual exposure.
[ Supply chain ]
Dependencies are a risk in their own right.
A modern application ships hundreds of open-source libraries. Each one is a potential entry point, and we treat it as such.
- Inventory of each project's dependencies
- Automatic alerts on known vulnerabilities
- Locked versions for reproducible builds
- Regular updates rather than emergency ones
- Assessment of a library before adding it
[ Code & testing ]
No code reaches production without review.
Code review is our first security filter. Automated tests and acceptance testing do the rest.
- Peer code review before every merge
- Automated code analysis in the CI/CD pipeline
- Security tests built into acceptance testing
- Penetration tests before go-live when criticality warrants it
- Security fixes handled as a priority
[ Operations ]
Detect, respond, recover.
You prepare for an incident before it happens. In production, we monitor, we know who steps in and how activity restarts.
Recovery objectives (acceptable downtime and data loss) are defined with you, project by project.
- 01Monitoring & alertingAvailability, performance and anomalies monitored, with alerts that reach the right people.
- 02ObservabilityApplication errors reported in real time (Sentry) so we can diagnose fast, before users report the problem.
- 03Incident managementTriage, containment, fix, then a documented post-mortem.
- 04BackupsAutomated, encrypted, stored separately from production. Restores are tested, not just assumed.
- 05DRP / BCPDocumented disaster recovery and business continuity plans for critical applications.
[ Data & GDPR ]
Your data stays yours.
GDPR compliance is not a cookie banner. It is handled in the architecture and in the contracts.
- Minimisation: collect only what is needed
- Retention periods defined and enforced
- Contractual framework for data processing
- Data subject rights considered from the design stage
- Access to production data limited and traced
[ Internal AI policy ]
AI, with rules.
Our teams use AI tools to be more productive, within a defined framework.
- No client data given to an AI tool without agreement
- AI tools approved internally, no free-for-all use
- Generated code reviewed and tested like any other code
- Architecture and security decisions made by humans
No system is invulnerable, and we don't claim otherwise. Our commitment is about means: documented practices your teams can verify, and a clear plan when an incident occurs.
[ In short ]
Security is not an option added at the end. It is a way of building.