SyncTrix logoSyncTrix
LegalLast updated

Security

How we secure our own systems and the systems we build for clients - access control, encryption, secure development, incident response, and how to report a vulnerability.

1. Our position on certification

We want to be precise, because vague security claims waste your team's time. SyncTrix does not currently hold a SOC 2 or ISO 27001 report of its own. What we do have is a set of operating practices described on this page, and substantial experience engineering systems that pass those audits for our clients.

If you need a certified vendor as a condition of contracting, tell us early and we will say so plainly rather than putting you through a procurement cycle that cannot complete. If you need evidence of specific controls, we can usually provide it directly - configuration, policy documents and records - which is often enough for a security review.

We would rather lose a deal on an honest answer than win one on an implied certification.

2. Access control

  • Multi-factor authentication is required on all business systems, including email, source control, cloud accounts and infrastructure.
  • Access is granted on the principle of least privilege, scoped to the role and the engagement.
  • Client system access is requested explicitly, granted for the duration of the work, and revoked at the end of it.
  • Administrative and production access is limited to named engineers who need it, and is reviewed periodically.
  • Accounts are removed as part of offboarding when someone leaves or moves off an engagement.
  • We do not use shared logins for production systems. Where a vendor forces one, access is brokered through a credential manager with an audit trail.

3. Encryption and data handling

Data in transit is encrypted with TLS. Data at rest in the databases and object storage we operate is encrypted using the platform's managed encryption. Secrets are held in a secret manager or encrypted variable store, never committed to source control.

We minimise what we hold. Where we need production-like data for debugging, we prefer anonymised or synthetic data, and where real data is unavoidable we agree the handling in writing first, restrict it to the engineers involved, and delete it when the work concludes.

ControlApproach
Transport encryptionTLS on all public endpoints
Encryption at restPlatform-managed encryption for databases and object storage
SecretsSecret manager or encrypted environment store, rotated on personnel change
Client production dataAccessed only with written agreement, minimised and time-boxed
LaptopsFull-disk encryption and screen lock required

4. Secure development

  • All changes go through pull request review before reaching production. Direct pushes to production branches are not permitted.
  • Dependencies are tracked and updated, with security advisories triaged rather than batched indefinitely.
  • Automated checks run in the pipeline, including type checking, tests and dependency vulnerability scanning.
  • Infrastructure is defined as code where practical, so changes are reviewable and reproducible rather than applied by hand.
  • We build authorisation, audit logging, input validation and rate limiting as default requirements rather than hardening added later.
  • Threat modelling is applied to features that handle payments, personal data, authentication or third-party integrations.

5. Infrastructure and monitoring

Systems we operate are monitored for availability and error rates, with alerting routed to people who can act. Logs are structured and retained for a defined period so that an incident can be reconstructed.

Backups are taken on a schedule appropriate to the data, and restores are tested rather than assumed - an untested backup is an assumption, not a safeguard. Recovery objectives are agreed with the client rather than left implicit.

6. Incident response

We maintain an incident process covering detection, containment, investigation, remediation and communication. Suspected security incidents are escalated immediately rather than triaged as ordinary defects.

If an incident affects a client's systems or data, we notify that client promptly with what we know, what we are doing and what we still need to establish, and we follow up with a written account of the cause and the corrective actions. Where notification to individuals or a regulator is required, we support the controller in meeting that obligation within the statutory timeframe.

Incidents produce follow-up actions with owners and dates. We treat unfixed causes as outstanding work, because an incident that recurs was never resolved.

7. Personnel

  • Employees and contractors are bound by confidentiality obligations covering client information.
  • Access to client environments is limited to the people staffed on that engagement.
  • Security expectations - credential handling, device security, reporting suspected phishing - are covered on joining and reinforced periodically.
  • Subcontractors, where used, are bound by equivalent confidentiality and security obligations, and clients are told when a subcontractor will have access to their systems.

8. Reporting a vulnerability

If you believe you have found a security vulnerability in this website or in a system we operate, please report it to [email protected] with enough detail to reproduce it. We will acknowledge your report, investigate, and tell you the outcome.

We ask that you give us a reasonable opportunity to remediate before disclosing publicly, that you do not access or modify data belonging to others, and that you avoid testing that degrades availability for other users - no denial of service, no automated scanning that generates significant load, and no social engineering of our staff or clients.

We will not pursue legal action against researchers who report in good faith and within those limits. We do not currently run a paid bug bounty programme, and we will credit you for a valid report if you would like us to.

9. Compliance work we do for clients

A large part of our engineering work is building systems that have to satisfy an external audit or regulation. That includes SOC 2 readiness, ISO 27001 alignment, HIPAA-aligned architecture, PCI DSS scope reduction, and GDPR and DPDP data handling - including deletion that actually removes data rather than hiding it.

This is delivery work rather than an attestation about SyncTrix. We can describe the controls we have implemented for comparable systems, and provide references, under a confidentiality agreement.

10. Questions and security reviews

Send security questionnaires and due diligence requests to [email protected], or by post to Digileaf Technologies Private Limited (CIN U63999TS2023PTC175586), Hyderabad, India. Tell us your deadline and we will tell you honestly whether we can meet it.

Where a question describes a control we do not have, we will say so and explain what we do instead. An accurate gap with a plan is more useful to your risk assessment than an evasive answer.