Security practices.
How client code, credentials and data are handled, set out for security and procurement review.
Effective and last updated
Our position
We are not SOC 2 certified and we will not imply that we are — a badge we have not earned is worth less than an honest description of what we actually do.
What follows is how we handle your code, your credentials and your data. If your procurement process needs something here formalised, ask; we would rather do the work than pass a questionnaire by wording.
This page describes our standard practices and is provided for information. It does not by itself create contractual obligations or warranties; the security commitments that bind us for an engagement are those set out in the signed agreement, which may add to or vary these practices. Personal data is handled in accordance with the Information Technology Act 2000, the rules made under it and the Digital Personal Data Protection Act 2023.
Access control
- Access is granted per project, to the named people on that project, and revoked when they leave it
- Multi-factor authentication is mandatory on every account that touches client systems — no exceptions and no shared logins
- Credentials live in a managed password manager, never in a repository, a ticket, or a chat message
- Production access is separate from development access and is granted only where the engagement requires it
- We review who has access to what at the end of every engagement, and on any team change
Device security
- Full-disk encryption on every device that touches client work
- Automatic screen lock, and remote wipe available on company-managed devices
- Operating system and browser updates applied within seven days of release
- No client source code on personal devices
Source code
Repositories live in your organisation from the first commit, not ours. You can see every change as it happens and you can revoke our access at any moment without us having to hand anything over.
- Branch protection and required review on anything merging to a release branch
- Automated dependency scanning, with known-exploitable vulnerabilities triaged within two working days
- Secret scanning on every push; a leaked credential is rotated before the fix is discussed
- Signed release builds, with signing keys held in your accounts
Client data
The strongest control here is the one that costs nothing: we try not to hold your data at all.
- We work against synthetic or anonymised data wherever it is possible to do so
- Where production data is genuinely required, it is accessed in your environment rather than copied into ours
- Nothing containing personal data is stored on a laptop
Third-party dependencies
Most real-world compromise arrives through a dependency rather than through our front door, so this is treated as a first-order concern rather than as housekeeping.
- Every dependency is pinned to an exact version; nothing floats
- A new dependency needs a reason in the pull request — convenience is not one
- Lockfiles are committed and reviewed like any other code
- We prefer a hundred lines we understand to a package we do not
Incident response
The commitment that matters is the timeline, so it is stated as one:
- Reportable cyber security incidents are reported to CERT-In within six hours of being noticed, as required by the CERT-In Directions of 28 April 2022 under section 70B of the Information Technology Act 2000
- Where we act as Data Fiduciary, personal data breaches are intimated to the Data Protection Board of India and to affected individuals as the Digital Personal Data Protection Act 2023 and its rules require. Where we act as a processor for a client, we notify the client without undue delay so it can meet its own obligations
- Logs relevant to an incident are retained for the period required by the CERT-In Directions
| Within 24 hours | You are told, with what we know and what we do not yet know |
|---|---|
| Within 72 hours | A written assessment: what happened, what was affected, what we have done |
| Within 14 days | A post-incident review, including what we got wrong |
| Ongoing | Any regulatory notification the incident requires, coordinated with you |
Reporting a vulnerability
If you have found a security issue in something we built or operate, write to security@mobilebytesensei.com. Include enough detail to reproduce it.
We will acknowledge within two working days, keep you updated while we fix it, and credit you publicly if you would like that. We will not ask you to sign anything before we accept a report.
If you act in good faith — you access only what is needed to demonstrate the issue, do not view, change, retain or disclose other people’s data, do not degrade the service, and give us reasonable time to fix the issue before disclosing it — we will not initiate legal action against you for that research. This commitment covers only systems we own or operate; it cannot authorise testing of systems owned by our clients or other third parties, and it does not affect the rights of anyone other than us.
We do not currently run a paid bounty programme. We will say so plainly rather than let you assume otherwise after doing the work.
Business continuity
Supplier continuity is a real risk to a client, and pretending otherwise helps nobody.
Everything we build lives in your accounts: repositories, infrastructure, stores, signing keys. Every engagement includes a runbook written so your team can operate the product without us, and a recorded handover. If we vanished tomorrow, you would have a bad month rather than a dead product.
Security questionnaires
We will complete yours. We answer honestly, including where the answer is "we do not do that" — a supplier who scores full marks on a questionnaire is usually a supplier who is guessing.
If a control you require is missing and reasonable, tell us and we will implement it rather than argue about the wording.
Questions about this document: write to legal@mobilebytesensei.com. A person responds.