Answering the Enterprise Security Questionnaire: Tenancy and Data Isolation for SaaS Document Features
There is a moment in every growing ISV’s life that founders remember precisely. The biggest prospect in the pipeline goes quiet for a week, and then an email arrives from someone you have never spoken to — a security assessor, a third-party risk team, a procurement portal — containing a spreadsheet with three hundred rows. Encryption, tenancy, data residency, incident response, penetration testing, subprocessors, deletion. The deal is now gated on your answers, and the questions are hardest wherever your product stores customer documents, because documents are where the customer’s most sensitive material lives: contracts, board papers, financial workings, personnel files.
This article is about answering that SaaS security questionnaire well when your product’s document features are built on SharePoint Embedded. The good news is that you are holding better cards than most vendors your size: a large share of the spreadsheet is answered by Microsoft’s platform and by the architecture of SharePoint Embedded itself. The discipline lies in knowing exactly which questions are answered for you, which are answered by your architecture, and which remain genuinely yours — and never blurring the three. That framing has a name: the shared responsibility model, and it should be the organising principle of every answer you write.
We work with SaaS and software vendors at exactly this stage — the first serious enterprise deals, the first serious security reviews — and the pattern is consistent. Vendors do not lose these reviews because their security is inadequate. They lose them because their answers are vague, overclaimed or improvised, which assessors read as a proxy for how the company will behave when something goes wrong.
Why Document Features Attract the Hardest Questions
A security assessor triages your product by asking where the damage would be if you were breached. Application data — records, workflow state, configuration — is sensitive, but documents are different in kind. A document store is a concentrated archive of exactly the material the customer’s own security programme exists to protect, in portable, self-describing files that are valuable the moment they are exfiltrated.
So expect the document sections of the questionnaire to be probed hardest, and expect follow-up calls to dwell there. Assessors will want to understand tenancy: whose infrastructure the documents sit on, what separates one customer’s files from another’s, and what stands between a bug in your code and a cross-customer disclosure. If your answers to those questions are crisp, the rest of the review tends to soften; if they wobble, everything else gets harder.
The Shared-Responsibility Model Is Your Answer Key
Every cloud product is a stack of responsibilities divided between the vendor and its platform providers. Assessors know this — they review vendors on AWS, Azure and Google Cloud all day — and what they are testing is whether you know it. The credible vendor answers each question by naming the layer that owns the control, describing how it is implemented, and pointing at evidence. The non-credible vendor claims everything (“all data is secured with bank-grade encryption”) and evidences nothing.
For a product whose document features are built on SharePoint Embedded, the stack has three layers:
- Microsoft’s platform answers questions about physical security, infrastructure, encryption and platform certifications.
- SharePoint Embedded’s architecture answers questions about tenancy, isolation and where documents physically live.
- Your application answers questions about authentication, authorisation, your permission mapping, your logging, your incident response and your own security practices.
If SharePoint Embedded is unfamiliar territory, we have written an introduction to what it is and how it works; the one-sentence version for this article is that your application stores documents in dedicated containers inside Microsoft 365, and users work on them through Microsoft’s own Office editing experience embedded in your product. Now let us take the three layers in turn.
Layer One: What Microsoft’s Platform Answers for You
Because the documents in a SharePoint Embedded application physically reside in Microsoft 365, an entire band of the questionnaire is answered by Microsoft’s platform controls rather than by anything you built:
- Physical and infrastructure security. Datacentre access controls, hardware lifecycle, network infrastructure — platform matters, evidenced by Microsoft’s published compliance documentation.
- Encryption at rest and in transit. Content in Microsoft 365 is encrypted at rest and protected in transit as a platform property. You did not implement this and should not imply that you did; you inherit it, and you should say so in exactly those words.
- Certifications and attestations. Microsoft 365 carries one of the broadest compliance portfolios in the industry, and Microsoft publishes its certifications, audit reports and control documentation for customer review. When a questionnaire asks for ISO or SOC evidence for the storage layer, your answer points there.
- Resilience and availability. Redundancy, failover and data durability for the document store are platform properties, backed by Microsoft’s service commitments.
The phrasing discipline matters more than it looks. Write answers in the form: “Document content is stored in Microsoft 365 via SharePoint Embedded and inherits Microsoft’s platform controls for encryption at rest and in transit; Microsoft’s certifications and audit documentation are available at [reference]. Our application-layer controls are described in section X.” Assessors deal in inherited controls every day. What they penalise is a vendor presenting a platform’s certification as if it were the vendor’s own — more on that below.
Layer Two: What SharePoint Embedded’s Architecture Answers
The tenancy and isolation rows are where most multi-tenant SaaS vendors sweat, because the honest answer for a conventional architecture is “logical separation via a tenant-ID column and disciplined query filters” — which is normal, but takes careful evidencing. SharePoint Embedded data isolation gives you a structurally stronger story to tell.
Containers are the isolation boundary. In SharePoint Embedded, documents live in storage containers, and the container is a hard, platform-enforced security boundary: permissions and access control attach at container level, enforced by Microsoft 365 itself rather than by a filter in your application code. A well-designed application gives each customer — often each workspace or engagement within a customer — its own container. Your questionnaire answer becomes: each customer’s documents are held in dedicated storage containers; isolation is enforced by the platform, not solely by application logic. That is a materially better answer than a shared bucket and a WHERE clause, and you should make sure your architecture has actually earned it before you write it.
Documents live in Microsoft 365, not in a vendor-run store. Your document layer is not a blob store you operate; it is Microsoft 365 storage governed by Microsoft’s operational controls. For multi-tenant document storage security questions — who patches it, who operates it, whose staff can touch the storage infrastructure — this shifts the answer from “trust our small operations team” to “the storage layer is operated by Microsoft”.
Residency follows the tenancy model — so know which model you run. In the standard SharePoint Embedded configuration, containers are created in each customer’s own Microsoft 365 tenant, which means each customer’s documents reside within their own tenant boundary and geography — for many assessors, the single most reassuring sentence in your whole response. In the alternative model, where containers live in your (the provider’s) tenant, residency follows your tenant’s geography instead, and your answer must say so plainly. Nothing corrodes credibility faster than a residency answer that turns out to describe an architecture you do not actually have. Whichever model you run, one sentence of truth beats a paragraph of borrowed reassurance.
Keep this layer’s answers at exactly this level of detail. The questionnaire is not asking you to defend your container partitioning strategy or your scaling design; it is asking whether isolation is real, enforced and locatable. Answer that, offer an architecture diagram, and stop.
Layer Three: What Remains Genuinely Yours
Here is the part no platform answers for you, and the part assessors most want to hear you own without prompting.
Authentication and authorisation in your application. Microsoft enforces container permissions, but your application decides who gets access to what. How you authenticate users, whether you support single sign-on, how sessions are managed, how administrative access to your own systems is controlled — all yours.
Permission mapping. Your product has roles, workspaces and sharing rules, and somewhere in your codebase they are translated into container permissions. That mapping is the single most security-critical code you own: a bug here is how a “platform-isolated” architecture still leaks a document. Expect a competent assessor to ask how it is tested. (For the technical shape of container permissions, see our article on building your first SharePoint Embedded application.) Have a real answer: code review on every change to the mapping, automated tests that assert cross-customer access fails, periodic access reviews.
Logging and monitoring. Which user accessed which document, when, from your application’s point of view; how long logs are retained; who reviews alerts. Platform-side activity signals exist, but your application-level audit trail is yours to build and yours to produce when a customer’s investigation team asks.
Incident response and breach notification. Who is on call, how incidents are triaged, and — the row enterprise buyers care about most — what you commit to contractually for notifying affected customers, and how quickly. “We would notify affected customers without undue delay, and our incident response plan is available under NDA” is a fine answer. Having no plan to attach is not.
Your own security practices. Secure development lifecycle, dependency and vulnerability management, penetration testing of your application by an independent firm, background checks, access control for your own staff and administrators. Microsoft’s platform testing does not cover your code; commissioning your own annual penetration test — and being willing to share the executive summary — is one of the cheapest credibility purchases available to a small vendor.
Subprocessors and data flows. Microsoft appears on your subprocessor list, along with anyone else who touches customer data. A simple data-flow diagram showing what lives where — documents in Microsoft 365 containers, metadata in your database, telemetry in your monitoring stack — answers half a dozen questionnaire rows at once.
Offboarding and deletion. When a customer leaves, what happens to their documents, on what timeline, and how is destruction evidenced? The container-per-customer model makes the honest answer straightforward — the customer’s containers are deleted, recycle-bin retention windows and all, and you confirm completion — but only if you have actually built and rehearsed the procedure.
Decoding the Rows That Decide the Review
A few questionnaire items come up in almost every review, and it is worth pre-writing strong answers.
“Is customer data segregated from that of other customers?” Yes — describe container-level isolation enforced by Microsoft 365, plus the application-layer permission mapping and how it is tested. Name both layers; the assessor is checking whether you know there are two.
“Where is our data stored and processed?” State the tenancy model you actually run, what that means for geography, and what metadata (if any) lives outside it in your own systems. Partial answers here read as evasion.
“Is data encrypted at rest and in transit?” Yes, inherited from Microsoft 365 for document content — say “inherited”, cite the platform documentation, and cover your own database and services in the same answer.
“Who at your company can access our data?” Answer for your staff and your administrative tooling, with role-based access and audit logging. “Nobody” is rarely true; “these named roles, under these controls, with this logging” is believable.
“Have you undergone penetration testing?” Answer for your application, with dates and the offer of a summary. Do not answer with Microsoft’s testing programme; that covers their platform, not your code.
“What happens to our data on termination?” Describe your offboarding runbook, timelines and confirmation. If you cannot describe it, build it before the next questionnaire, not after.
The Answers That Sink Deals
Having watched these reviews from the vendor’s side of the table, the fatal answers are remarkably consistent. “We’ve never thought about that” — or its written form, a blank cell — on incident response, deletion or staff access, which tells the assessor your security posture is reactive. Overclaiming, most commonly presenting Microsoft’s certifications as if they were audits of your company; assessors check, and one discovered overclaim taints every other answer in the workbook. Vagueness dressed as strength — “military-grade encryption”, “fully isolated architecture” — with no mechanism named; specific and modest beats vague and grand every time. And treating the questionnaire as an adversary rather than a buying signal: by the time the spreadsheet arrives, someone on the other side wants to buy your product and needs your help getting it past their own risk process. Answer like a partner, not a witness.
The vendors who clear enterprise review are rarely the ones with the most controls. They are the ones who can say, for every row: this is answered by our platform, and here is Microsoft’s evidence; this is answered by our architecture, and here is the diagram; this is ours, and here is what we do. That is the whole game.
Build the Evidence Pack Once
Your first questionnaire will consume a fortnight; there is no reason the fifth should consume more than an afternoon. Assemble a standing evidence pack: an architecture and data-flow diagram, a one-page shared-responsibility statement mapping controls to layers, your latest penetration test summary, your subprocessor list, your incident response and deletion procedures, and pointers to Microsoft’s compliance documentation for the inherited layer. Review it quarterly. Beyond saving time, the pack changes the tone of reviews — a vendor who sends a coherent security overview with the completed spreadsheet reads as an organisation that has done this before, and assessors extend measurably more benefit of the doubt to vendors who look prepared.
How McKenna Consultants Can Help
McKenna Consultants has spent more than 25 years building Microsoft document integration for software vendors, and much of that work has been for products sold into exactly the buyers who send these spreadsheets — including accelerating Word and Excel Add-In development for AuditBoard, whose platform serves audit, compliance and risk teams, and building mobile document workflows for SaaS vendors like Slidebank. Our SharePoint Embedded development engagements are designed with the security review in mind from the first architecture decision: container isolation models you can defend in writing, permission mappings with tests an assessor can be shown, and tenancy choices whose residency consequences are understood before a customer asks.
If your document features are heading into enterprise security review — or the spreadsheet has already landed and some of the rows have no good answer yet — get in touch. We can help you build the architecture the answers describe, and the evidence pack that gets the deal through.
