Security at XProgrammers

Security posture

Security isn't a department here — it's how senior engineers work by default. We're a small, senior team, which means fewer hands touching your systems and a shorter path from decision to control. We design for least privilege, encrypt by default, and assume any system can be targeted.

Because much of what we do is rescuing software others built — often AI-generated MVPs shipped without a security pass — hardening is a first-class part of the job, not an afterthought. The section on hardening client code covers exactly what that means.

Data handling

We minimise the data we touch and classify what we hold so it gets the right level of protection.

• Minimisation. We ask for the least access that lets us do the work, and we prefer test or anonymised data wherever a task allows it.
• Classification. Client data is treated as confidential by default; personal and regulated data gets the strictest handling.
• Segregation. Each client's materials are kept logically separated, never co-mingled across engagements.
• Disposal. On hand-off, we return or destroy client data on request and revoke our access — covered in the DPA.

Access control

Access is granted narrowly, reviewed regularly, and revoked quickly.

• Least privilege. Engineers get only the access a specific task needs, scoped to a single engagement.
• MFA everywhere. Multi-factor authentication is mandatory on our accounts and any client systems we operate.
• SSO & password hygiene. Single sign-on where available, a managed password vault, and no shared credentials.
• Joiner/leaver discipline. Access is provisioned on assignment and removed within hours of an engagement or team change.
• Audit trails. Privileged actions on systems we manage are logged and reviewable.

Encryption

We encrypt data in transit and at rest as a baseline, not an upgrade.

• In transit. TLS 1.2+ for all traffic to our services and between systems we operate; modern cipher suites, HSTS on our web properties.
• At rest. AES-256 (or provider-equivalent) on disks, databases, and backups for the systems we control.
• Secrets. Credentials and keys live in a managed secrets manager or vault — never in source control, tickets, or chat.
• Key management. Keys are rotated on a schedule and on suspicion of compromise.

Vendors & subprocessors

We keep our vendor list short and choose providers with strong, independently-audited security. Before a subprocessor touches client data, we review their controls and bind them by contract.

• Due diligence. We prefer vendors with SOC 2, ISO 27001, or equivalent attestations.
• Contractual protection. Data protection terms and confidentiality flow down to every subprocessor.
• Transparency. We maintain a current subprocessor list and notify engaged clients before adding one that processes their data.
• Right to object. Clients under a DPA can object to a new subprocessor, as set out in the DPA.

Secure SDLC

Security is built into how we ship, not bolted on at the end.

• Code review. Every change is peer-reviewed by a senior engineer before it merges.
• Automated checks. Static analysis, dependency and secret scanning run in CI on every pull request.
• Dependency hygiene. We track known vulnerabilities and patch on a risk-based schedule.
• Least-privilege pipelines. CI/CD uses scoped, short-lived credentials, never long-lived personal tokens.
• Environment separation. Development, staging, and production are isolated, with production data kept out of lower environments.

Incident response

We plan for incidents so a bad day is a managed one. Our process is to detect, contain, eradicate, recover, and learn.

• Detection. Logging and alerting on systems we operate, with a clear path to escalate.
• Notification. For engaged clients, we commit to prompt notification of a confirmed breach affecting their data — within the timeframe set in the DPA (without undue delay, and aligned to 72-hour expectations).
• Containment. Documented runbooks to isolate affected systems and rotate credentials fast.
• Post-mortems. Blameless reviews with concrete, tracked remediation.

How we harden client code

This is the part most “security pages” skip — and it's central to what we do. A working demo is not a secure product. When we take over code that an AI tool or a hurried team shipped, hardening it is the job. A typical rescue pass includes:

• Auth & authorization audit. Closing open endpoints, fixing broken access control, and removing the “anyone with the link” defaults that AI scaffolds love.
• Secret sweep. Finding hardcoded keys and tokens in the repo and its history, rotating them, and moving them into a vault.
• Input & injection hardening. Validating inputs and closing SQL, command, and XSS injection paths.
• Dependency & supply-chain cleanup. Removing abandoned or vulnerable packages and pinning what's left.
• Data exposure review. Locking down over-permissive APIs, storage buckets, and database rules.
• Logging & observability. Adding the audit trail that lets you actually see an incident.

You get the findings, the fixes, and a written hand-off so the hardened state is the new baseline — not a one-time clean-up.

Business continuity

We keep backups of systems we operate, test restores, and document recovery steps so an outage or device loss doesn't become a data-loss event. Recovery objectives for a specific engagement are agreed in the contract.

Compliance & data protection

We build to recognised frameworks and support our clients' obligations. We offer a Data Processing Agreement for GDPR-regulated work, support EU Standard Contractual Clauses for transfers, and align our internal controls with SOC 2 and ISO 27001 practices. We're happy to complete reasonable security questionnaires for prospective clients.

Reporting a vulnerability

If you believe you've found a security issue in something we run, please tell us. Email security@xprogrammers.com with enough detail to reproduce it. We'll acknowledge promptly, keep you updated, and we won't pursue good-faith researchers who follow responsible disclosure.