Engineering

Lead Security Engineer

Own security for the product and the platform: architecture, cryptography, application and cloud posture, pipeline gates, detection and incident response. You report to the Head of Engineering with a direct line to the CEO.

Apply now

Location

Greater Noida · Hybrid

Type

Full-time, permanent

Reports to

Head of Engineering

Experience

7+ years

Why this role

Data-blind by design, provable to a regulator, and a tenant boundary that is a breach — you own all three.

Security authority with real teeth — you can block a release

Cryptography that makes data-blind true: envelope encryption, key hierarchies, crypto-shredding

Tamper-evident consent ledger, provable seven years from now

Inherit a real architecture, independently review it, and put your name to it

The work

What you'll actually do

What you'll own

Cryptography and key management — envelope encryption, per-tenant and per-principal key separation, customer-managed keys for Data Fiduciaries who demand them, crypto-shredding for erasure, and rotation that never orphans a seven-year-old record
Ledger and receipt integrity — the signing keys, signing path and evidence chain behind our tamper-evident consent ledger, with a verification path a third party can run without trusting us
Cloud security posture and residency — SCP guardrails across a multi-account AWS Organization, IAM Identity Center with no standing production access, break-glass that is logged and alerted, KMS key policy, and proof that no personal data, backup or log sits outside India
Application and SDK security — authorisation for every actor including nominees and guardians, tenant isolation with the tests that prove it, signed outbound withdrawal callbacks, and a supply chain for an SDK that ships into customers' websites: signed releases, SRI, CSP, iframe sandboxing and a kill-switch
Shift-left and supply chain — code, dependency, secret and IaC scanning in GitLab CI/CD as blocking gates with a documented exception path, and every finding in a running workload traced back to the repository and commit that introduced it
AI and LLM security — secure patterns for Amazon Bedrock, RAG pipelines and vector stores; mitigations for prompt injection, data poisoning and SSRF; governance against the OWASP Top 10 for LLM Applications and MITRE ATLAS. No model sees personal data, and every model call stays in-region
Detection and incident command — GuardDuty, CloudTrail and Security Hub turned into alerts someone acts on, logs kept tamper-evident for 180 days in India; you are the named incident commander and own the CERT-In six-hour report and the DPDP notifications
Assurance and portability — penetration tests, VAPT and tenant-isolation testing scoped and closed; CIS, ISO 27001/27701 and DPDP requirements expressed as continuous automated checks; and a live assessment of which controls are provider-managed and what replaces them when we move to sovereign data centres
Standards and the team — secure-by-design guidelines, threat models and design reviews written with the Head of Engineering, and coaching so security is something the team does, not something done to it

The three hard problems

Data-blind by design — personal data routed through the platform must not be readable by us, across keys, logs, backups, support access and debugging sessions; it cannot be retrofitted
Provable to a regulator — you protect the keys, the signing path and the evidence chain so the proof still holds when the reader assumes we are lying, including seven years from now
A tenant boundary is a breach, not a bug — one organisation must never see another's data through the API, the console, the database, the SDK or an AI agent; you design the controls, and the tests that let us say so with evidence

Minimum qualification

7 years of security engineering experience, at least 3 of those as the lead or senior-most security engineer for a production software product, where you owned the design decisions rather than executing someone else's
Applied cryptography you have designed, not just used — envelope encryption, key hierarchies and rotation on AWS KMS or an HSM, certificate lifecycle and mTLS; you can explain from experience what breaks when a key rotates under a multi-year retention obligation
Deep AWS security: IAM policy and trust boundaries you have had to debug, KMS key policies, SCPs across a multi-account Organization, VPC segmentation, and CloudTrail, GuardDuty and Security Hub logging designed for an auditor rather than a dashboard
Application security on a JavaScript/TypeScript codebase — OAuth2/OIDC and JWT, authorisation and multi-tenant isolation design, the OWASP Top 10 and API Top 10 as things you have found in review, and the browser security model: CSP, SRI, CORS and postMessage
Threat modelling as a practised discipline, on systems you then had to build and defend, with written threat models you can talk us through
Security gates in CI/CD that you built — SAST, SCA, secret and IaC scanning in GitLab or GitHub that block a build, with a documented exception path somebody signs
Incident response you personally led as incident commander, with a written postmortem behind it
Terraform you can read critically and write guardrails in, and Python or shell for detection and remediation automation
The judgement to separate real risk from scanner noise, and to explain the trade-off to engineers and leadership in plain language

Preferred

Tamper-evident or append-only structures in production — hash chaining, Merkle trees, signed receipts, RFC 3161 trusted timestamping and third-party verifiability
Multi-tenant isolation designed and then proved, with the authorisation testing that shows the boundary holds
Customer-managed keys (BYOK/HYOK), HSM or KMIP delivery for enterprise customers
Hands-on running of a CNAPP/CSPM such as Wiz, or AWS-native security services operated at depth — the CNAPP decision is still open and is yours to make
Securing LLM integrations — Amazon Bedrock, RAG pipelines and vector stores, the OWASP Top 10 for LLM Applications, MITRE ATLAS
Supply-chain security for code that ships into other people's products: signed releases, SBOMs, build provenance (SLSA)
Owning technical controls under DPDP, GDPR, ISO 27001, ISO 27701 or SOC 2, and producing evidence for an external auditor
An incident reported under a statutory clock, to CERT-In or a sectoral regulator such as RBI, SEBI or IRDAI
Customer-facing security assurance — questionnaires, VAPT reports, architecture calls with BFSI or enterprise security teams, and a security whitepaper you wrote
Security beyond one cloud — private, on-premises or sovereign deployment, and control design that survives the move
Offensive experience that informs your defence — OSCP, professional penetration testing or credible bug bounty results — and AWS Certified Security – Specialty, CISSP or CCSP

How we work

Hybrid working style with anchor at our Grandthum office in Greater Noida, Tech Zone IV
Defined core collaboration hours — outside that, flex your day around its natural shape
Architecture decisions get written down and argued in the open. Small, reviewable changes. Depth is valued over volume
Company-issued devices and approved tooling for anything touching customer or compliance data. Given what we build, we hold ourselves to the standard we sell

The practical details

Location: Grandthum, Tech Zone IV, Greater Noida West, Gautam Buddha Nagar, Uttar Pradesh
Employment type: full-time, permanent
Reports to: Head of Engineering, with a direct line to the CEO
Education: B.E./B.Tech or M.Tech in CS/IT
Offers are subject to standard background verification, which we will explain before we ask for anything

How we'll interview you

A 30-minute conversation with our Head of Engineering
A security architecture session on our actual constraints — data-blind processing, a key hierarchy that must still verify a record in 2033, tenant isolation, an SDK running on someone else's site, and an AI agent. No trivia quizzes
An applied review — we hand you a slice of an architecture you have never seen, with real-looking cloud and code findings, an IAM policy and a Terraform module; you tell us what you would need to know before you put your name to it. Then you walk us through something you once secured that turned out to have a hole in it
A conversation with the founder about the company, the regulation and where this goes
Four stages. We aim to complete them inside two weeks and to give you a decision either way
With your application: in one paragraph, tell us about a security property you had to prove to somebody who assumed you were wrong — what was the property, what evidence did you produce, and what could you not prove? We read this first

Being straight with you about the stage

We are under twenty people and pre-revenue, with a product that has to be right before a regulator looks at it
You will have real authority over our controls and tooling, with very little cover
The upside: the decisions are yours, the platform is new enough to secure properly rather than patch, and the market opening is real and dated
The downside: it is early — some tooling decisions are still open, the hours around launches and audits will be uneven, and part of the job is building the security function rather than running one

Ideal candidate

You'll thrive here if this sounds like you

You have already been the senior-most security engineer on a production product — you designed security, not just configured it

You have defended your decisions to people with the authority to reject them: auditors, regulators and enterprise security teams

You can separate real risk from scanner noise, and explain the trade-off in plain language

You would rather reconstruct an architecture, test its assumptions and decide what you are prepared to put your name to than patch blindly

If you have never secured consent or privacy infrastructure, that is fine — almost nobody has; the Rules that create this category were notified in November 2025

Apply