What cybersecurity questions will LPs ask?

The thirteen areas, and what each question is really about

Every one of these traces back to data you hold on somebody else's behalf.

• Investor data. What you hold, where it lives, and who can reach it. This is the question underneath most of the others.
• Portfolio company information. Board material, metrics, and cap tables belonging to companies who trusted you with them.
• Access controls. Who has access to what, how it is granted, and how it is removed when somebody leaves.
• Authentication. Whether multi-factor authentication is in place across the systems that matter, which NIST lists among its small business topics.
• Incident response. Whether a plan exists, who runs it, and whether it has ever been exercised.
• Vendor risk. Which providers hold your data, what their controls are, and what your agreements say about a breach at their end.
• Backups. That they exist, that they are separated from production, and that a restore has actually been tested.
• Encryption. Data at rest and in transit, described as a practice rather than as a configuration.
• Phishing. The most common route into a firm of this size, and the reason training and payment verification controls are asked about together.
• Employee training. That it happens, on a cadence, including for partners.
• Business continuity and disaster recovery. What happens when systems, an office, or a person is unavailable.
• Breach notification. Who you would tell, in what order, and within what timeframe, which is partly a legal question in most jurisdictions.
• Data retention. What you keep, for how long, and what you delete, which intersects with privacy obligations.

A framework to organise the answer

Allocators do not expect a first-time manager to hold a certification, and they do respond well to an answer organised against a recognised structure rather than assembled ad hoc.

The NIST Cybersecurity Framework, published as CSWP 29 in February 2024 as version 2.0, organises cybersecurity risk management around six Functions. In NIST's own descriptions: Govern addresses the organisation's context, cybersecurity strategy and supply chain risk management, roles, responsibilities and authorities, policy, and oversight of the strategy. Identify and Protect concern understanding assets and securing them to prevent or lower the likelihood and impact of adverse events. Detect enables the timely discovery and analysis of anomalies, indicators of compromise, and other potentially adverse events. Respond supports the ability to contain the effects of incidents. Recover supports the timely restoration of normal operations and appropriate communication during recovery.

Used honestly, that structure lets a two-person firm answer a long questionnaire coherently: here is who governs this, here is what we hold, here is how it is protected, here is how we would notice, here is what we would do, here is how we would come back. NIST also maintains a small business corner collecting guidance for organisations without a security team, which is the right starting point for a first fund rather than an enterprise standard.

The non-sensitive evidence checklist

What to have ready, described at a level that answers the question without becoming a map of your defences.

• A named person accountable for security, even where the work is outsourced.
• A written policy, dated and reviewed, covering access, devices, and data handling.
• A statement that multi-factor authentication is enforced on the systems holding investor and portfolio data.
• A joiner and leaver process, with evidence it has been followed.
• An incident response plan naming who is called, in what order, including counsel and your administrator.
• Evidence that a backup restore has been tested, with the date.
• A vendor list identifying which providers hold your data, with the date each was reviewed.
• A training record showing the team completed something, on a cadence.
• A payment verification control, described as a process.
• A business continuity plan with a date it was last exercised.

What to leave out of any document that circulates: specific tooling and versions, network topology, security gaps and their remediation timelines, credentials or access structures, and the details of any past incident beyond what you are obliged to disclose. Those belong in a conversation with the allocator's own security reviewer, not in a data room folder.

How the ask scales with the allocator

The questions are the same; the format and the depth differ.

• Family offices often ask conversationally and are satisfied by a coherent description of the process.
• Institutional allocators and consultants send a written questionnaire, sometimes a dedicated security one, and expect dated evidence rather than assertions.
• Public investors may add breach notification expectations and, in some jurisdictions, obligations that flow from their own status to yours.
• Development finance institutions and public programmes add data protection and reporting requirements as conditions, which Blueprint's directories describe per institution.
• Any allocator whose own regulator has been active on this recently will ask more, which is a moving target rather than a fixed bar.

What limited partners are testing

Not whether you are secure, which nobody can verify from a questionnaire, but whether you take custody seriously.

• Does the manager know what data they hold and where it is?
• Is somebody accountable, or is security a shared assumption?
• Has anything been tested, or does the evidence consist entirely of documents?
• Would the manager recognise an incident and know who to call?
• Does the manager over-share security detail when asked, which is itself a finding?

What this page does not do

It publishes no operational security detail and no configuration guidance, deliberately. Describing how a small fund is defended, on a public page, is describing how to attack one.

It also creates no standard. The NIST framework is voluntary and is described here as a way to organise an answer, not as a bar a fund passes or fails, and nothing on this page certifies anything.

This page is educational and general. It is not legal, cybersecurity, or data protection advice. Controls, breach notification obligations, and vendor terms should be settled with a qualified security professional and with counsel.