It's subjective opinion and depends on the purpose of the policy, who the policy controls and who reads it. If it helps, think about the information security policy like the HR Expenses Policy, or the Anti-Bribery Policy. I have seen specifics in the expenses policy regarding the mileage rate and general statements about submitting in time. Infosec policies can be regarded as similar.
Generally, infosec policies are either end user policies, eg don't use USB, or IT department policies, eg all end points must have USB disabled. Then there are baselines and standards: All end points must have End Point Protector X installed. Then procedures: install X version Y from location Z. Sometimes you want to mix them up and sometimes you don't.
It depends on who you are writing your policy for. Some policies are designed to be read by third parties to get through the compliance hurdle. Where companies are audited by independent auditors such as for ISO 27001 or where a company has, say, regulated clients then the auditors will look at the policy and look for edge cases where the company does not comply. In those policies, the author may decide not to write "version X is needed" but rather "use the latest version if it is available and possible to install". Or they may want to unambiguously tell users "your passphrase must be > X characters".
Policies are often written to be seldom updated. Perhaps an annual refresh. For some regulated industries there can be a huge inertia to changing the policy, but less for the baseline. So the policy says "implement the baseline" and then the baseline says "configure X with Y". The majority of policies will, I suspect, be written this way. I don't have any peer reviewed data to support that assertion, but most policies that I review tend towards the general rather than the specific but then will call out specifics if the business dictates. For example a policy might say "all websites must use TLS" but a policy for a company that has to be PCI-DSS compliant might say "all websites must use TLS 1.2 or better" (or whatever the standard is now ... that's the problem): the policy might even be utterly generic "all websites must have appropriate security controls in place as determined by a risk assessment". Where policies are used as the lever to control the business then this could well be the case.
As a rule of thumb, when deciding what level of detail to put into your policy:
- Consider the audience
- Consider if the policy is there to merely get through compliance
- Consider that an organisation may get audited against policy and non-compliance against your own policy is generally regarded as a Bad Thing
- Consider if anyone will actually read the policy
- Consider if a baseline configuration baked into the devops process is a better place for configuration
- Consider if you need to have a some specifics, particularly if there is a minimum acceptable baseline
