Someone in the compliance department took a 110-page international security framework, pasted it into a corporate Word template, and ran a global find-and-replace. Every instance of “should” became “must.” The chief information security officer signed it to get the document published before the end of the quarter. The board approved it on a consent agenda. Nobody read it. Six months later, an external auditor asked for the evidence.
A policy that says “must” in 1,200 places is not a strong policy. It is a list of 1,200 things the auditor can ask you to prove. Auditors do not test your environment against the framework or the regulator’s guidance document. They test your environment against your own policies. The standard’s “should” is a floor. Your “must” is a ceiling you now have to reach. You can scope out a control in a framework. You cannot scope out your own policy.
Consider a custodian bank that adopted a policy requiring critical security patches within 30 days. The policy was lifted from a modern cloud-native framework. The bank’s mainframe and settlement systems, however, run on vendor release cycles that operate on 90-day intervals. The security team knew this. The person who wrote the policy did not. The auditor sampled six months of patch records for the critical systems and found six instances of non-compliance. The finding was not against a regulator. It was against the organization’s own document.
An asset manager’s policy required annual security assessments of “all third-party vendors with access to confidential data.” Procurement produced a spreadsheet of 600 contracted suppliers. The technology team produced a different list of firms with direct production connectivity. The security team had the capacity to assess 40 vendors per year. The auditor asked which list defined “all.” The hard part of the word “all” is the inventory. If the policy does not define the population, the auditor will assume the population is everything.
Institutional finance runs on systems built before modern frameworks existed. A blanket mandate applied across an entire estate will eventually hit a 25-year-old custody platform that physically cannot support the required control. An engineering lead once had to explain to a risk committee why a core ledger system could not support a 15-minute idle session timeout mandated by the new corporate policy. The policy was copied from a framework that assumed modern web applications. The engineering lead had to ask for a permanent exception, which triggered a mandatory report to the national prudential regulator. Legacy systems do not care about your new verbs.
This happens when organizations bypass the risk assessment. Frameworks are menus, not recipes. The risk assessment is the mechanism that dictates which items to order and which to ignore. The Statement of Applicability is the document that connects the standard to the organization. It names what you are doing, what you are not, and why. Most organizations treat it as a compliance artifact to be finished before the certification audit. It should be the working document that drives the policy. When you copy the whole catalog and harden the verbs, you skip the one step the standard actually requires.
A copy-pasted framework passes the test for design effectiveness. It looks comprehensive on paper. It immediately fails the test for operating effectiveness because the organization lacks the tooling, headcount, or architecture to generate the evidence the policy now legally requires. An auditor does not read the policy and nod. They sample controls, ask for evidence over a period, and compare what happened to what the policy says should happen. If the policy says “quarterly,” the auditor expects four instances in twelve months. If the policy says “must” and the evidence shows a different frequency, that is a nonconformity.
When a policy is too rigid for the reality of the IT estate, engineers are forced to file policy exceptions for routine operations. These exceptions accumulate. During an audit, a high volume of exceptions is treated as a systemic failure of governance, even if each individual exception is technically justified. An approved exception needs an owner, a rationale, compensating measures, an expiry date, and an accepting authority. An undocumented deviation is not an exception process. An exception you have documented is a control. An exception you have not is a nonconformity.
The problem compounds in third-party risk. Vendor questionnaires ask if you have a policy that requires specific controls. You say yes because the policy says “must.” The vendor’s security team relies on that answer. When the auditor finds the gap, it becomes a misrepresentation in due diligence, not just an internal finding. Stripping scoping statements from frameworks also applies strict standards to the wrong environments. A rigorous encryption standard meant for a specific cardholder data environment gets inadvertently applied to the pension fund’s internal cafeteria menu server.
The fix requires reversing the order of operations. Risk assessment comes first. What are the actual risks to this organization? Control selection comes second. Pick the controls from the catalog that address those risks. Policy language comes third. Write at the level you can operate. Use “must” only where you have evidence. Use “should” where you have guidance. Use “may” where you have options. If you cannot describe the artifact that proves a control, do not write it into the policy.
Keep policy commitments distinct from procedures. A policy can require periodic access review based on risk. A controlled procedure specifies the cadence, the systems, the reviewers, and the records. This puts changing operational detail where it can be maintained without rewriting the policy. The people who do the work must read the draft. If the operators read the policy and laugh, revise it.
Writing an aspirational policy is the fastest way to document your own non-compliance. Every “must” in an information security policy is a promise. The auditor’s job is to check whether you kept it. A policy you cannot execute is just a confession. The fix is not to write a stricter policy. The fix is to write a policy that describes the organization you actually run, and then improve the organization.