Asked in a diligence session who is responsible for information security, mid-sized companies typically answer with a description rather than a name: the person who built the systems, the team that runs the servers, or an outsourced IT service provider. Asked in the same meeting who is responsible for financial reporting, the answer comes back without hesitation as a title, attached to a person with signature authority, a defined reporting line, and annual objectives. The asymmetry between the two answers does not arise from indifference toward security; more often than not the company has funded security seriously, replaced its firewall, built backup infrastructure, and in some cases worked through a certification process. The distinction lies not in whether the spending occurred, but in whether the authority directing that spending has ever been assigned.
The origin of the gap is the way information security enters a corporate structure in the first place. In nearly every company, security begins not as an independent function but as an attachment to the unit standing closest to it technically — IT operations — because in the early days the question genuinely is a technical one and the person who built the system is the only person who can answer it. That choice is rational at formation: defining a separate role costs more than the risk being carried at that stage. The problem lies not in the shortcut itself but in the shortcut persisting after the conditions change; even once the company begins holding customer data, integrating with enterprise clients, and operating across multiple locations, security still sits beneath the team that built the systems.
What this configuration produces structurally is not an excessive workload but a closed review loop. When the person granting access rights is also the person reviewing whether those rights were correctly granted, the accountability mechanism may appear present on paper while failing to operate in practice; no one reports his own decision as a finding, not out of bad faith, but because he already considers that decision correct. The same mechanism becomes more visible in exception handling: when an urgent customer request arrives, the decision to deviate from the access policy rests with the discretion of the person who wrote the policy, and the exception is recorded nowhere. Within a few years the company accumulates a quietly widening gap between its written policy and its actual practice, and the only person positioned to measure that gap is the person creating it.
The same structure surfaces differently along the documentation dimension. An information security policy usually exists; what remains unclear is who approved it, on what date, when it was last reviewed, and what findings that review produced. The policy was written once — typically to complete an enterprise customer's supplier questionnaire or to pass a certification audit — and has since remained outside daily operations. That distinction emerges quickly at the diligence table, where what is sought is not the existence of the policy but the trail of decisions flowing from it: who received access to which system and when, which accounts were closed within what period following which departure, and which vendor was granted access to what scope of data. Absent those records, the practice itself is treated as unverifiable, since documentation is the only ground on which verification can rest.
The measurement dimension is the most misleading surface in the entire review. Asked how many security incidents have occurred, many companies answer zero and present that answer as a performance indicator. Where no detection capability has been built, however, zero incidents reports an absence of visibility rather than an absence of events; where no logs are collected, no anomaly is ever raised. An experienced reviewer therefore asks not for the incident count but for the existence of an incident definition, for who is obliged to report at which threshold, and for how many notifications were raised over the past twelve months and how many were closed. The difference between zero notifications and zero incidents is not a technical nuance but a direct signal about management quality.
Along the continuity dimension, the question is not how well security is managed but what remains transferable if a single individual departs. In many companies the administrator credentials for critical systems, root access to cloud accounts, domain registrar logins, and control over backup infrastructure are concentrated in one person, frequently the founder or the first technical hire. That concentration is read not as a trust problem but as a transferability problem: the acquirer asks who will grant the company access to its own infrastructure on the first day after closing, and an answer naming a person rather than a procedure raises closing risk directly. The place where founder dependency is measured most concretely is often not the income statement but the access inventory.
The channel through which this reaches valuation typically runs through deal structure rather than price, which is why sellers tend to notice it late. Facing a target where information security ownership is undefined, a buyer will not reduce the multiple so much as expand the scope of representations and warranties, requesting separate and longer-surviving statements covering data breach, personal data compliance, and the security commitments embedded in customer contracts. The escrow percentage standing behind those statements rises, the survival period lengthens, and the indemnity cap is pulled toward a larger share of consideration. Economically, the discount is taken not from the price but from the tail risk the seller continues to carry after closing; the nominal figure appears preserved while the risk-adjusted amount reaching the seller shrinks materially.
The second channel is the calendar. A security function with undefined ownership does not generate a single finding in diligence; it generates a chain of findings, each unanswered question producing the next. The absence of access logs prompts a request for penetration testing, the findings of that test prompt a remediation plan, and the question of who will execute the plan prompts a condition precedent to closing. That chain may not break a transaction on its own, yet it can extend the closing timetable by the length of a full budget cycle, and every added week works against the seller to the extent that it reopens any variance in the target's operating performance as a matter for renegotiation.
The intervention that neutralises this pattern is neither a technology investment nor a thicker policy document; it is a structural repositioning of ownership. The arrangement BEIREK builds in this area rests on three separated components: first, attaching security decisions to a role distinct from the line that operates the systems — this role need not be full-time, but it must not report into IT operations and it must carry its own budget line; second, operating a single decision register in which critical access grants, exceptions, and vendor data-sharing arrangements are recorded at the moment of request rather than the moment of approval; third, presenting the access inventory, the open exceptions, and the reported incidents in writing to the board or the shareholders on a quarterly review rhythm. This trio does not by itself raise the technical level of security; what it raises is the demonstrability of the level already achieved.
The second layer of intervention converts the structure's independence from the founder into evidence. An access inventory is compiled for critical accounts, with a primary and a secondary custodian defined separately for each item; the departure and handover procedure is exercised at least once during an actual personnel change and its outcome recorded, since the only proof that a procedure works is a procedure that has been run, not one that has been written. On the same logic, the incident definition and the notification threshold are fixed in writing, so that a figure of zero notifications becomes a result measured against a defined threshold rather than a claim about visibility. Once twelve to eighteen months of such records have accumulated, the answer given in diligence ceases to be an assertion and becomes a verifiable file, and the ground of the warranty negotiation shifts accordingly.
None of these arrangements reduces the company's security risk to zero, nor is that their purpose. What they aim at is making visible from the outside by whom, under what authority, and against what record the risk is managed — because what is priced at the diligence table is not the risk itself but the quality of the evidence that the risk is being managed. Where two companies share the same technical infrastructure and one records and reports its decisions on a regular cadence while the other conducts the same work without a trail, the difference between them is institutional rather than technical, and it is that difference which shows up in the deal structure.
There is a single-question test for whether a company's information security ownership has genuinely become institutional: for an exception granted to the security policy in the past twelve months, does the documentation show who approved it independently of the person who requested it? If the answer is visible, ownership rests on a mechanism rather than a title; if it is not, then however well the company's security posture has been funded, it will be priced in diligence as a temporary arrangement sustained by one individual rather than as a transferable institutional capability.