Skip to content
sedwis

Security

How we protectyour code andyour data.

Specific enough to answer a vendor assessment, and honest about what we don't yet have.

If you're running a vendor assessment, this page should answer most of it. Anything it doesn't, ask — we'd rather answer a hard question early than discover a blocker at contract stage.

Practices

What we actually do.

01

Access control

  • Least-privilege access; engineers get only the systems their project requires
  • Mandatory two-factor authentication on all Sedwis accounts and client systems we hold
  • Access reviewed at project start and revoked within 24 hours of someone leaving a project
  • Shared credentials are prohibited — every action traces to an individual
02

Code & repositories

  • Client code lives in the client's own repository wherever possible
  • Mandatory peer review before merge; no direct pushes to main
  • Automated dependency scanning with Dependabot, and secret scanning on every commit
  • Secrets never committed — environment variables and secret managers only
03

Data handling

  • TLS 1.2+ in transit and encryption at rest as standard
  • Production data is not copied to developer machines; we work with anonymised or synthetic data
  • Data residency honoured — Indian, EU, UK, UAE, Canadian, Australian or Singapore regions as required
  • Retention limited to what the engagement needs, then deleted
04

Infrastructure

  • Infrastructure defined as code, so changes are reviewable and reproducible
  • Network isolation, private subnets and security groups scoped to purpose
  • Automated backups with restores actually tested — an untested backup is not a backup
  • Monitoring and alerting on the metrics that precede an incident
05

Application security

  • Parameterised queries throughout; no string-concatenated SQL
  • Input validated server-side regardless of client-side checks
  • Security headers including CSP, HSTS and frame protection
  • Rate limiting and abuse protection on all public endpoints
06

People

  • Background and reference checks before anyone joins a client project
  • NDAs signed by every individual, not just at company level
  • Security awareness training on joining and annually
  • Devices encrypted, screen-locked and centrally managed

Ownership

You own everything, from day one.

Not on final payment. Not on project completion. From the first commit.

  • Source code, in your repository under your organisation
  • Cloud accounts and infrastructure, in your name and billed to you
  • Domain names, DNS and third-party service accounts
  • Documentation, designs and architecture decisions
  • Full IP assignment written into the contract, not discussed at the end

We build so you can leave. That's not a concession — it's the only arrangement that keeps us honest.

Incident response

What happens if something goes wrong.

01

Detect & contain

Monitoring alerts a human. First action is containment, not diagnosis.

02

Notify you

Within 24 hours of confirming an incident affects your data — before we fully understand it, not after.

03

Investigate

Scope, cause and affected data established, with a written timeline.

04

Remediate

Fix deployed, credentials rotated, access reviewed.

05

Report

Written post-incident report including what we got wrong and what changes.

What we don't have

The claims we're not making.

Any security page can list good practices. This is the part that tells you whether to believe the rest of it.

  • We are not ISO 27001 or SOC 2 certified.

    Both are on our roadmap. We follow the practices above, but we won't claim a certification we don't hold — and you should be wary of any vendor who is vague on this point.

  • We are not a managed security provider.

    We build and operate systems securely. We don't do penetration testing of our own work — for anything sensitive we'd recommend an independent tester, and we'll help you scope it.

  • We use third-party services.

    Cloud hosting, email delivery, error tracking and, where you've agreed, AI providers. We'll give you the full sub-processor list on request, before you sign anything.

Before you share anything

NDA on request, always.

We'll send one before the first call, or work under yours. You shouldn't have to describe your idea to get protection for it.

Reporting a vulnerability

Tell us, and we'll fix it.

If you've found a security issue in anything we run, email contact@sedwis.com with the subject “Security”. We'll acknowledge within one business day and won't pursue anyone reporting in good faith.

Running a vendor assessment?

Send us your questionnaire. We complete them as a matter of course and will flag anything we can't satisfy rather than leaving it blank.