Build it as though a security questionnaire is coming, because one is
If your software touches an enterprise customer's data, someone will eventually send you a security questionnaire. Answering it honestly is straightforward when access control, audit logging, retention and subprocessors were designed in. It is expensive and sometimes impossible when they were not, and that cost lands during a sale rather than during the build.
American enterprise buyers run vendor reviews, and those reviews reach further down the supply chain every year. A system built without them in mind does not fail loudly. It fails where a deal is otherwise agreed, a questionnaire arrives, and the honest answers are the ones that stop it. What is being tested is not the feature set but whether the system can account for itself.
A team builds an internal tool that works well, and a customer asks to use it. The questionnaire arrives: who can see this data, how do you know who saw it, how long do you keep it, who else processes it on your behalf. The system updates records in place, so there is no history of who changed what. Permissions are a single admin flag, so access cannot be described in terms of roles. Deletion removes the row and leaves it in backups and a log aggregator nobody inventoried. All of that is fixable, but retrofitting history into a system that never recorded it is a rewrite of the data layer, and the deal has a timeline the rewrite does not fit.
When this work makes sense
Questions worth asking any supplier
Does the design describe permissions as roles rather than an admin flag, because a reviewer asks what a role can reach and a boolean cannot answer that.
Is the audit log append-only and exportable, because a log the application can edit is not evidence to a reviewer.
Does deletion reach backups, logs, caches and analytics, because a retention promise only holds where the data actually lives.
Will you get a current list of every third-party service the system sends data to, because that list is a direct question on most questionnaires.
Is environment separation real, because shared credentials between staging and production undo every other control in the answer.
Deliverables
A role-based access model documented in a form you can hand to a reviewer, not only written in code
Append-only audit logging of who did what to which record and when, with export
A retention schedule per data type, implemented in the system rather than described in a policy document
Deletion that reaches backups, logs and downstream services, with the limits stated honestly
A maintained subprocessor list covering every third-party service the system sends data to
Separated environments, managed secrets and a documented access path for production
The technical section of a standard security questionnaire, completed from how the system actually behaves
Built with
Process
We start by asking who will review this system and what they will ask, before any architecture is agreed. If the answer is an enterprise procurement team, that shapes the data model immediately: identity and roles, an event history rather than in-place updates, a retention decision per data type. These are cheap when chosen at the start and expensive later, which inverts the usual order of work, the boring compliance-shaped questions come before the interesting product ones. Where no external party will ever review it, we say so and build something simpler rather than selling controls nobody needs.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to approach a security review
Build the controls in from the start
Fits: Anyone expecting to sell to an enterprise buyer within the life of the system
Limits: Costs more before a customer is asking for it, which is a real decision when budget is tight
Build lean, remediate when a deal demands it
Fits: Early products still testing whether anyone wants them
Limits: Remediation then arrives on the buyer's timeline, and the data layer is the part that cannot be rushed
Buy a platform that carries the controls
Fits: Common workflows where a vendor already holds the reports
Limits: You inherit their roadmap and limits, and data you move outside the platform is back on your side of the questionnaire
Case studies
No published US custom software case study yet. Systems built for security review are rarely ones a client wants described publicly. Our New York office is at 1 Liberty Street, 23rd Floor. Client work will be published when we have permission and outcomes that can be evidenced.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Can you get us through a SOC 2 audit?
No. We are not auditors and hold none of those reports ourselves, so we cannot assess or attest to anything. What we can do is build a system whose behavior matches the answers you want to give, and produce the technical evidence an auditor asks for. The audit itself belongs to an accredited firm and your compliance adviser.
Why does audit logging have to be append-only?
Because the reviewer's question is not whether you have logs but whether the logs can be altered by the thing they are recording. An append-only history, stored where the application cannot rewrite it, is the difference between evidence and a report. It also changes how you model data, which is why it is a design decision rather than a feature.
What is a subprocessor list and do we need one?
It is a current list of every third party your system sends customer data to, including hosting, email delivery, error tracking and analytics. Enterprise customers ask for it, and contracts often require notice before it changes. Most teams can produce it only by reading their own code, which is why we maintain it as the system is built.
Our data is in backups. Can we really delete it?
Within limits, and the honest answer is what matters. Backups expire on a cycle rather than instantly, and saying so plainly is usually acceptable to a reviewer, whereas claiming immediate deletion everywhere is not credible. We implement deletion where it can be implemented and document where it is bounded; your counsel decides whether that meets your obligations.
Do we need single sign-on straight away?
Only if your buyers require it, and enterprise buyers commonly do. The thing to plan for is that retrofitting identity is harder than adding it, because it touches every assumption about how a user exists in your system. Designing with an external identity provider in mind costs little; migrating to one after launch does not.
Who on your side can see our data?
As few people as the work allows, under named access rather than shared credentials, and with production access separated from development. Where our engineers in India need access, that is disclosed and covered by the contracting arrangements described on our US page. If you need access restricted further, say so before the build and it can be designed in.
What about privacy laws across different states?
Several states have their own privacy laws, and which apply depends on where your customers are and what data you hold. We are not attorneys and that determination rests with your counsel. What the system can do is make compliance achievable: knowing what data exists, who touched it, how long it is kept and how a deletion request is carried out.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.