AI Security for Life Sciences: Secure What AI Can Reach

Microsoft has published the clearest statement of this problem available anywhere, and it is worth quoting exactly because it comes from the vendor selling the assistant rather than from anyone selling a remedy. On its Core Infrastructure and Security Blog, dated 23 July 2026, Microsoft observes that the effort of manually locating and correlating documents “was never designed as a formal security control”, and that with an assistant in place, “Copilot makes data once hidden by volume discoverable by intent”. That sentence is the entire category in eleven words.

Read it carefully, because the two halves do different jobs. The first half is an admission: the security posture of most enterprise content estates has, for years, depended on a control nobody designed, documented, tested or owned — the sheer difficulty of finding anything. Nobody wrote that control down. Nobody could have passed an audit on it. It worked anyway, in the same accidental way that a filing cabinet in an unlit basement works. The second half explains what removes it. An assistant does not search by folder or by memory. It searches by intent, across an index, at the speed of a sentence.

The corollary is that the vendor statements everyone quotes as reassurance are true and beside the point. Microsoft documents that Copilot and its agents “retrieve data from Microsoft Graph and respect existing permissions, sharing settings, and policies”, and that “Copilot only accesses data that an individual user is authorized to access”. Both are accurate. Neither says anything about whether those permissions are correct. Read as an answer, the sentence closes the conversation. Read correctly, it opens it, because the permission map has now become the only thing standing between a user and every document that map has ever reached.

Microsoft makes the amplification argument explicitly rather than leaving it to be inferred. Its Purview documentation states that generative AI “amplifies the problem of oversharing data”. Its Copilot deployment blog states that “any gaps in governance, such as over-permissioned sites, inherited access, or lack of sensitivity label protections, become amplified”, and — the sentence that should defuse most of the internal politics around this work — that “most internal oversharing stems from configuration issues rather than malicious user intent”. This is not an insider-threat conversation. It is a configuration debt conversation with a new deadline.

The practical consequence for a life-sciences company is that the AI decision and the information-security decision have collapsed into the same decision. A company can run an excellent vendor review of its assistant, sign a strong data processing agreement, disable model training, choose a regional deployment, and still hand every employee a fast, indexed, natural-language interface to a permission map that has never been read. That is the risk this service line exists to measure and reduce, and it lives entirely on the customer side of the shared-responsibility line.

Microsoft, 23 July 2026: the friction of manually locating and correlating documents “was never designed as a formal security control”, and Copilot “makes data once hidden by volume discoverable by intent”.

Permission sprawl is not a failure event. It is the sum of a decade of individually correct decisions. A grant made for one project in 2021 on a folder that later acquired children. A group created for a study that closed. A departing employee whose account was disabled but whose group memberships were not. A guest account created for a contract research organisation transition that outlived the transition. Each defensible on its own; collectively, an access map nobody has read end to end.

The defaults do most of the work. Microsoft states outright that “by default, SharePoint sets sharing settings to the most permissive option”, and its own list of the signals that make a site high risk reads as a free audit checklist: broad Anyone, Everyone or organisation-wide links; large audiences with excessive permissions; broken permission inheritance and complex access models; sensitive content with weak protection; unlabeled or public sites; and ownerless, inactive or unreviewed sites. Every one of those is a normal condition in a company that has been running for a few years, and none of them produces an alert.

Two specific mechanisms deserve naming because they are the ones that surprise people. The first is the Everyone Except External Users claim, which Microsoft documents as granting access to every internal member of the tenant — including, as its own reporting makes explicit, employees who have not yet been hired. A site secured with that claim in 2019 is open to a person who joined last week. The second is the anonymous sharing link. Microsoft states in its sharing documentation that Anyone links can be forwarded and that activity through them cannot be attributed to a specific person, which is the reason they are a discovery problem rather than merely a sharing preference.

At a clinical-stage biotech client, during a first engagement, connected AI reached employee-information files in Box through existing user permissions. Nothing in the AI tool was misconfigured. No control failed. The files were reachable by those users before the assistant existed; the assistant simply made that reachability legible for the first time. That is the shape of the finding in almost every environment we look at, and it is why the remediation is a content and identity project rather than an AI project.

The remediation surfaces exist and most companies have never run them. SharePoint Data Access Governance reports produce a site permissions baseline, a per-user permissions view, Everyone Except External Users activity and sharing link activity. Site access reviews delegate remediation to the people who can actually see item-level detail, which is the compliance-correct path as well as the scalable one. Restricted Access Control provides a genuine container-level lock for the cases where discovery controls are not enough. None of this requires a new product; it requires someone to own the output.

A large amount of published advice on this topic is now out of date, and the fastest way to lose a technical reader is to recommend a control that Microsoft has retired. Restricted SharePoint Search was the 2024-era stopgap: an allow list of up to 100 sites. Microsoft’s documentation now carries a retirement notice stating that “starting July 31, 2026, new enablement is blocked”. Restricted Content Discovery is the replacement.

What matters more than the transition is what Microsoft says about both features in the same breath. Of the retiring one: “Restricted SharePoint Search isn’t a security boundary and doesn’t change any permissions on SharePoint sites”, and it “doesn’t guarantee that only sites on the allow list show up in search or in Copilot”. Of the replacement: “Restricted Content Discovery doesn’t change existing permissions”, and “the feature doesn’t remove content from the Microsoft 365 search index”. Both are discoverability controls. Neither is an access control. That distinction is the single most useful idea to hand a buyer, because it determines whether a control belongs in a remediation plan or in a compensating-control register.

The operational traps are worth planning around too. Microsoft documents that for sites with more than 500,000 items, an update to Restricted Content Discovery “could take more than a week to fully process and reflect in search and Copilot experiences”. It also warns that “excessive use can reduce the amount of content available to organization-wide search”, which is the quiet cost of using a discovery brake as a substitute for fixing permissions: the assistant becomes less useful without becoming meaningfully safer. Restricted Content Discovery additionally requires a Copilot licence and SharePoint Advanced Management, so it is not a free lever.

The measurement instruments have limits that are equally worth knowing before they appear in a report as though they were tenant-wide truth. The default Purview data risk assessment for oversharing “automatically runs weekly for the top 100 SharePoint sites based on usage”. Custom assessments cap at 200,000 items per location and item-level scanning covers a small number of sites. These are useful tools and they are not a census. A finding phrased as a tenant-wide statement on the strength of a top-100-sites scan is a finding that will not survive scrutiny.

The correct posture, and the one Microsoft itself recommends, is sequential: run the content management assessment and the governance reports first, remediate what they surface, apply discoverability controls only to the residue that cannot be remediated in time, and treat that residue as a documented exception with an owner and a date. Discovery controls are a bridge, not a destination.

Everything above concerns the source system. There is a second layer that most reviews never reach: the retrieval index itself. Search and retrieval-augmented systems do not consult your file server at query time. They consult a copy, with a copy of the access control data attached, and those two copies fall out of step in documented, predictable ways.

Microsoft’s Azure AI Search documentation on SharePoint access control lists is the most useful single source on this anywhere, precisely because it enumerates the failure modes rather than glossing them. It states that between synchronisation runs “the index serves stale ACL data”, which means a permission you corrected this morning may still be honoured in its old form by the retrieval layer this afternoon. It documents that permissions applied at a parent scope do not necessarily propagate to indexed children, that some link types are not represented at all, and that the remedy is an explicit permissions resynchronisation followed by re-testing. That last point is the operational one: a fix is not verified until the same query has been re-run after resync.

The general mechanics are worth understanding because they apply to every vendor, not only Microsoft. Security trimming in a search index typically works by comparing a filter value to a stored field, and the documentation is refreshingly blunt about what that means: the principal is just a string. The index has no notion of your directory, your group nesting or your revocations. It has a value that was correct at indexing time. Graph connectors add their own semantics, including an explicit Everyone entry type and deny-over-grant evaluation, both of which have to be modelled deliberately rather than assumed.

Non-Microsoft platforms have the same class of problem with different names. Elastic documents that its document-level security relies on access-control fields being present, and that content without them is not restricted by that mechanism — a fail-open behaviour that is entirely reasonable as an engineering decision and entirely dangerous as an unexamined default. The general rule to take away is that a retrieval system inherits permissions at indexing time, not at query time, and the gap between those two moments is where findings live.

The design answer is to authorize before retrieval rather than after generation, which is also what the current OWASP guidance says. Sensitivity-label-aware retrieval, where the index carries the label and the query respects it, is the strongest pattern available in the Microsoft stack today, and it only works if the labels exist and mean something — which is the build described on our classification and access model page, linked below.

This field moved substantially in the last twelve months, and version currency is the fastest available credibility test. Two changes matter for anyone writing or buying in this space, and a third gives the whole subject a foundation older than any of the vendors involved.

The OWASP Top 10 for LLM Applications is now the 2026 edition, published 4 August 2026 by the OWASP GenAI Security Project, and it supersedes the widely circulated 2025 list. Two changes are structurally important. Excessive Agency moved from sixth place to third, which reflects the shift from chat assistants to systems that call tools and take actions. And a new entry, LLM08:2026 Hidden Context Exposure, addresses content that reaches the model without the user seeing it — retrieved passages, system instructions and policy text acting as context. The methodology behind the ranking is unusually transparent: community judgment carrying three-quarters of the weight, and analysis of thousands of real incidents from public vulnerability and AI-harm databases carrying the rest. Any page still citing the 2025 identifiers is telling you when it was written.

The second change is the arrival of a companion list for the architecture that is actually being deployed. The OWASP Top 10 for Agentic Applications, published 9 December 2025, runs from ASI01 Agent Goal Hijack through ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities and ASI06 Memory and Context Poisoning to ASI10 Rogue Agents. Its predecessor and companion, Agentic AI Threats and Mitigations, dates from February 2025. Together with MITRE ATLAS — which now carries agentic techniques including AI agent context poisoning, AI agent tool poisoning and retrieval-augmented generation credential harvesting — these give a life-sciences reviewer a shared vocabulary that does not have to be invented per engagement.

The government frameworks provide the governance scaffolding rather than the technique detail. NIST’s AI Risk Management Framework 1.0, released January 2023, organises the work into govern, map, measure and manage, and its Generative AI Profile, NIST AI 600-1 of July 2024, carries the sections on data privacy and information security that a regulated buyer will cite. NIST’s Cybersecurity Framework 2.0 gives the access-control mapping most quality systems already understand. NIST AI 100-2 E2025, the March 2025 adversarial machine learning taxonomy, is the correct citation for attack terminology — the 2023 edition is the one usually quoted and is out of date. The joint CISA, NSA and FBI guidance on AI data security adds the principle that output should be classified at the same level as the input data, which is the cleanest one-line summary of why an assistant inherits your classification problem.

None of this is new thinking, and it is worth saying so. Saltzer and Schroeder set out least privilege and open design as protection principles in 1975. What has changed is not the principle but the consequence of ignoring it: for fifty years, over-broad permissions were a latent liability, and the latency has now been removed.

The HIPAA Security Rule is more useful here than it is usually given credit for, because it was drafted in language that survived the arrival of retrieval systems. The technical safeguards standard at 45 CFR §164.312(a)(1) requires technical policies and procedures that allow access “only to those persons or software programs that have been granted access rights”. That phrase — persons or software programs — means an assistant or a retrieval connector is already in scope, without any interpretive stretch.

The precision that separates a credible report from a generic one is knowing which specifications are Required and which are Addressable. Within §164.312(a)(1), Unique user identification and Emergency access procedure are Required. Automatic logoff and Encryption and decryption are Addressable. Encryption at rest for electronic protected health information is, as the rule currently stands, an addressable implementation specification rather than a required one, which means a covered entity may implement an equivalent alternative measure and document why. Vendors routinely assert the opposite because it sells encryption. Getting it right is worth more than any amount of urgency, and it changes the remediation conversation from buy a product to document a decision.

The specifications that permission sprawl actually violates sit next door. §164.308(a)(4)(ii)(C) requires a covered entity to establish, document, review and modify a user’s right of access — review is the operative verb, and it is the one a decade of accumulated grants fails. §164.308(a)(3)(ii)(C) requires procedures for terminating access when a workforce member leaves, which makes a still-enabled account in a permission-trimmed index a rule problem rather than merely untidy. §164.312(b) requires mechanisms that record and examine activity, which is where the agent-mediated audit gap described above lands. And the minimum necessary standard at §164.502(b), with its implementation specification at §164.514(d)(2), requires the entity to identify the persons or classes of persons who need access and the categories of information each needs. A retrieval system whose effective corpus per persona has never been measured cannot demonstrate that.

For European operations the same facts land under different articles. GDPR Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary, which an unscoped index is the textbook counter-example to. Article 5(2) requires the controller to be able to demonstrate compliance — demonstrate, not intend. Article 32 requires ongoing confidentiality and explicit consideration of unauthorised disclosure of or access to personal data, and Article 32(4) requires the controller to ensure that a person under its authority does not process personal data except on instructions. An assistant that surfaces personal data to an employee who has no instruction to process it is an Article 32(4) problem before it is a security problem.

This is the part that converts we should tidy up our permissions into we cannot answer an inspector. Two distinct obligations in 21 CFR Part 11 are routinely collapsed into one, and a report that collapses them will not survive review by a quality unit that reads the regulation for a living.

21 CFR 11.10(d) requires “limiting system access to authorized individuals”. 21 CFR 11.10(g) requires “use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand”. These are different controls. The first is about who can get in. The second is about what a person who is legitimately in is permitted to do. A retrieval system that surfaces content to an authenticated user who has no business function requiring it is an 11.10(g) question even when 11.10(d) is satisfied. Separately, 11.10(e) requires secure, computer-generated, time-stamped audit trails, which is why the audit-trail behaviour of any AI layer is itself in scope.

EU GMP Annex 11, in operation since 30 June 2011, adds the clauses that most directly describe this work. Clause 12.1 requires physical or logical controls to restrict access to authorised persons. Clause 12.3 requires that creation, change and cancellation of access authorisations be recorded — a record, not a policy. Clause 12.4 requires the identity of operators entering, changing, confirming or deleting data to be recorded with date and time. Clause 9 requires audit trails to be available, convertible to an intelligible form, and regularly reviewed. Clause 11 requires periodic evaluation covering security and validation status.

The strongest external support for recurrent access review is not from a security framework at all. PIC/S PI 041-1, the July 2021 guidance on data management and integrity, sets out least privilege by role, segregation of administrator duties, and a maintained user list used in periodic reviews. WHO Technical Report Series No. 1033, Annex 4 adds a documented access system, retention of inactivated users, and no shared or generic logins for GxP data. These are inspectorate documents, not vendor whitepapers, and they carry weight in rooms where a security framework does not.

The draft revision of Annex 11, issued for consultation in July 2025 with the consultation closing in October 2025, would sharpen this considerably. It adds a dedicated identity and access management section stating the least privilege principle — users should not have higher access privileges than necessary for their job function — and a recurrent access review requirement whose stated purpose is to detect accesses which should have been changed or revoked during daily operation but were accidentally forgotten. That is a description of permission sprawl, written by a GMP regulator. It remains a draft: no final Annex 11 text exists as of 27 August 2026, and it must be described as a draft every time. One correction worth making, because several consultancies get it wrong: the draft Annex 11 contains no mention of artificial intelligence or machine learning at all. Its relevance here is access management and audit trail, which is strong enough on its own.

The draft Annex 11 identity and access section describes recurrent review as a way to detect accesses that should have been revoked but were accidentally forgotten. Draft status matters, and so does the fact that a regulator wrote the definition of permission sprawl.

There is a strong commercial temptation to present the regulatory picture as more settled and more urgent than it is. Resisting that is the whole credibility play, because the buyer’s quality and legal functions already know the status of these documents and will notice immediately if a page overstates it.

The most striking AI text in the GMP world is a draft. The new Annex 22 on artificial intelligence, issued for the same July 2025 consultation, applies to static and deterministic models and states that dynamic models which continuously and automatically learn and adapt during use should not be used in critical GMP applications. It goes further and says, verbatim, that “the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications”, while requiring that in non-critical applications qualified personnel remain responsible for ensuring outputs are suitable, that is, a human in the loop. That is the clearest regulatory signal on record and it is not in force. It is a draft, it is scoped to manufacturing of medicinal products and active substances, and critical GMP application means direct impact on patient safety, product quality or data integrity. It does not ban large language models from pharmaceutical companies. As of 27 August 2026 no final Annex 11 or Annex 22 text exists.

The EU AI Act picture changed materially in 2026 and most published timelines have not caught up. The Digital Omnibus on AI is Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. It defers the bulk of the high-risk obligations: stand-alone Annex III high-risk systems move to 2 December 2027, and high-risk AI embedded as a safety component of a product regulated under Annex I, which includes medical devices, moves to 2 August 2028. What did not move is as important: the Article 5 prohibited practices, the general-purpose AI model obligations that have applied since August 2025, and the Article 50 transparency duties that took effect on 2 August 2026. A page telling a biotech that high-risk obligations bite next year is wrong, and a page telling it that nothing applies yet is also wrong.

Two further documents matter for anyone whose AI output will touch a regulatory submission. The EMA reflection paper on the use of artificial intelligence in the medicinal product lifecycle places responsibility squarely on the sponsor, applicant, marketing authorisation holder or manufacturer to ensure that all algorithms, models, datasets and pipelines are fit for purpose, and states that where a third-party model is used in a context with high regulatory impact or high patient risk, the manufacturer of the system is expected to have provided details through a methodology qualification process. FDA’s draft guidance on the use of artificial intelligence to support regulatory decision-making proposes a seven-step, risk-based credibility assessment anchored on a defined context of use; it remains draft.

The practical translation is the same in every case. Responsibility does not transfer. Draft Annex 11 §7 states it in the sharpest available form: where a regulated user relies on a vendor’s qualification of a system used in GMP activities, that does not change the requirements, and the regulated user “remains fully responsible” for those activities based on the risk they constitute to product quality, patient safety and data integrity. No certificate, attestation or vendor assurance moves that obligation, which is why vendor assessment in this industry is a different instrument from a security questionnaire.

A clinical-stage or commercial-stage life-sciences company of fifty to five hundred people is usually not a software company, has usually never sold to a security-reviewing buyer, and usually holds no SOC 2 report and no ISO/IEC 27001 certificate. Then a large pharmaceutical partner, a licensing counterparty or an acquirer sends a two-hundred-question workbook with a two-week turnaround.

The first thing worth knowing is that the generic instruments and the life-sciences instruments test different things, and answering one does not answer the other. SOC 2, ISO/IEC 27001, the Shared Assessments SIG and the Cloud Security Alliance CAIQ test whether an organisation runs a competent security programme. EU GMP Chapter 7, Annex 11 and ICH Q10 test something the security frameworks never touch: whether the regulated user remains able to discharge a legal responsibility it is not permitted to delegate. Chapter 7 §7.5 requires the contract giver to assess the legality, suitability and competence of the contract acceptor — three tests, of which a SOC 2 report speaks to at most one. Chapter 7 §7.11 requires prior evaluation and approval before work is subcontracted, which for an AI vendor whose model provider is a subcontractor is a hard requirement rather than a courtesy notice. Chapter 7 §7.13 states that outsourced activities may be subject to inspection by competent authorities: a software vendor selling into GMP can be inspected.

The second thing worth knowing is that a certificate is not always the right purchase. Both SOC 2 Type 2 and ISO 27001 require evidence generated continuously over an observation window, and a company with no dedicated security owner will produce gaps in that window which become exceptions in the report. If no customer has asked and no deal is gated on it, buying one speculatively converts a sales problem into a fixed annual cost of surveillance audits, recertification and bridge letters. And if the buyer is a GMP manufacturer, the certificate answers a question they did not ask; the budget goes further on a validation support package, an audit-ready quality manual and a contract with GxP-competent clauses.

What does work, in order, is unglamorous. Publish a completed CAIQ, which is free and pre-empts a large share of inbound questionnaires, and for an AI product the CSA AI Controls Matrix now provides an AI-specific equivalent. Write the control narrative once and build an answer bank keyed to it. Get a real penetration test with a remediation record, because a current test with findings closed is more persuasive to a technical reviewer than a Type 1 report. Fix the contract layer: a data processing agreement with genuine GDPR Article 28(3)(h) audit rights, a named sub-processor list with notification, a business associate agreement template where protected health information is involved, and for GxP buyers an exit strategy and pre-release testing clause. Publish a trust page stating plainly what you have and what you do not. Then, when a named deal requires it, start the certification clock.

That sequence is the substance of our security questionnaire readiness work, and its most valuable output is often the list of questions where the honest answer is currently no. A reviewer who receives an accurate no with a dated remediation plan trusts the rest of the document. A reviewer who catches one optimistic yes stops trusting all of it.

Engagements in this service line are led by an independent security architect with seventeen years in information security, named to you in the engagement letter. They are a specialist on our expert bank rather than an employee, and we state that plainly because the distinction matters to anyone assessing who will actually be in the room.

A decade of those seventeen years was spent on the central security team of a major enterprise infrastructure vendor, serving every business unit in the company. That is an unusual vantage point and it is the relevant one for this work. A central team does not own a product; it reviews everyone else’s. The remit covered design and architecture review, security requirements review, source code review, penetration testing and vulnerability response — the full arc from a design document nobody has built yet to an incident in something shipped years ago. Reviewing hundreds of other teams’ systems, across a large and heterogeneous estate, is exactly the skill an exposure review or a vendor assessment requires, because both are exercises in reading somebody else’s architecture quickly and accurately.

Before that came several years of client-facing security consultancy, leading mobile penetration testing for Android and iOS. Consulting is a different discipline from internal security work: the report is the product, the client is not obliged to agree with it, and the finding has to be defensible to an engineer who wrote the code and does not want to hear it. That combination — a decade of internal central-team review plus client-facing consulting before it — is why the reports produced in this service line are written for the person who has to act on them rather than for the person who commissioned them.

The academic and research record behind the work is substantial and is shared with clients on request: a postgraduate degree in computer science with a security specialisation, multiple US patents in security engineering, and a peer-reviewed publication record across journals and conferences. The specialist practises as principal of an independent consultancy.

We describe the individual rather than gesturing at a security team, because a life-sciences buyer is entitled to know whose judgment they are purchasing. The specialist is named to you directly in the engagement letter, before you sign it, and the same person is referred to across the six child pages in this service line as a named security architect on our expert bank.

Three governance commitments apply to every engagement, and each of them exists because the opposite is common enough in this market to be worth ruling out explicitly.

Independence first. The person who reviews a system did not build it. Where IntuitionLabs has implemented something for a client — an information layer, a retrieval pattern, a classification model — we say so and scope any subsequent assessment so that the reviewer is not marking their own homework. This is the same logic that governs the certification professions, and it is worth understanding why they are so strict about it. AICPA independence rules hold that a firm which accepts responsibility for designing, implementing or maintaining internal control has created a management participation threat that no safeguard can reduce to an acceptable level. ISO/IEC 17021-1:2015 states that a certification body and any entity under its organisational control shall not offer or provide management system consultancy, defining that consultancy to include preparing manuals or procedures and giving specific advice towards implementation. Those rules are why an auditor cannot build your programme — and therefore why a preparation role exists at all.

Authorization second. Any testing activity happens only under a signed authorization letter that enumerates the systems and areas in scope, the window, the named signatories with actual authority, the halt conditions and, critically, the exclude list. This is not paperwork theatre. NIST’s technical testing guidance devotes an appendix to the rules of engagement and names the exclude list explicitly as any system not authorized for testing. The legal frame reinforces it: the United States Supreme Court in Van Buren v. United States held that a person exceeds authorized access when they obtain information from areas of a computer that are off-limits to them, which is exactly why an authorization letter must enumerate areas rather than merely state intent. Where a system runs on a cloud provider, the provider’s own testing policy applies on top of the client’s permission, and those policies differ meaningfully between vendors.

Evidence handling third. A security engagement generates the most dangerous artefact in a client’s estate: an indexed description of how to compromise them. Evidence is encrypted in transit and at rest, custodians are named, retention after report delivery and retest is defined in the contract, and real production records are never retained as proof. A redacted proof-of-access artefact demonstrates the same finding without creating a second copy of the data. Engagements carry professional liability and cyber insurance.

Findings in a regulated environment go into the client’s existing deviation and corrective action process rather than into a parallel security backlog. That is not a stylistic preference. In a company with a quality system, a finding that lives outside that system is a finding that cannot be tracked to closure in a way an inspector will accept.

IntuitionLabs was founded in 2023. It holds neither SOC 2 nor ISO/IEC 27001 itself. It is not an auditor and not a certifying body. On a security service-line page these facts belong in plain sight rather than in a footnote, because a buyer will establish them in ten minutes and a page that obscured them has answered the only question that mattered.

Take them in order. Founded 2023 means we do not have a decade of company history to point at, and we do not claim one. What we point at instead is the record of the named practitioner leading the work and the primary sources behind every assertion on these pages. Any consultancy can assert experience; the checkable version is a bibliography and a named person.

No SOC 2 and no ISO 27001 means exactly what it says. We are a small consultancy, not a platform holding customer data at scale, and we have not purchased a certificate we could not currently sustain the evidence window for. If your procurement process requires a certified supplier for this category of work, that is a legitimate requirement and we will say so at the first conversation rather than at the end of one. Our own posture and the controls we do operate are set out on our security page and our Trust Center, both linked below, which are about IntuitionLabs itself rather than about client engagements.

Not an auditor and not a certifying body is the most consequential of the three. We prepare; we do not certify. We build the control narrative, the evidence pack and the answer bank; a CPA firm performs a SOC 2 examination and an accredited certification body assesses an ISO management system. We do not issue certificates, attestations or conformity assessments, and any provider that offers to certify you and build the thing being certified is describing a conflict that the certification professions have written explicit rules to prevent. That prohibition, as set out above, is precisely what makes preparation a real and legitimate service rather than a euphemism.

The same boundary applies to our regulatory positioning. We are a Veeva X-Pages Partner and a member of the Claude Partner Network. Neither of those is a security certification, neither implies endorsement of our security services, and neither is offered here as evidence of anything beyond what it says. Where our work touches validated systems, the client’s quality system and qualified stakeholders determine the applicable assurance approach; legal and regulatory accountability stays with the organisation, which is what draft Annex 11 §7 says and what ICH Q10 §2.7 has said since 2008.

We prepare, we do not certify. The rule that forbids your auditor from building your programme is the same rule that makes an independent preparation role legitimate.