An information security policy is one short document that states what the organisation requires, and it sits on top of a set of standards and procedures that say how. Collapsing the two is the usual mistake: a policy that specifies a password length has to be reissued and re-agreed every time the standard moves, and a policy nobody can reissue is a policy that goes stale on the shared drive.
What the policy itself states
Scope, ownership, the classification scheme, the requirement to protect information according to its classification, the requirement to report incidents, and the consequence of not doing so. NIST defines a security policy as the set of laws, rules and practices that regulate how an organisation manages, protects and distributes sensitive information, which is a definition about requirement rather than mechanism. Keep the mechanism out and the document stays true for years.
What belongs in the standards beneath it
Password and authentication requirements, encryption choices, endpoint configuration, logging, retention periods, supplier requirements. These change, and they should be able to change without a fresh signature from every employee. The relationship is the useful part of the structure: the policy says information classified as confidential must be protected in transit, the standard says how, and only the policy needs an acknowledgement.
The framework question, answered honestly
You do not need to adopt a framework to have a usable policy, and you should not pretend to have adopted one you are not working. If you are heading for a customer's security questionnaire, mapping your policy set to a published structure makes the answers easier, and the NIST Cybersecurity Framework's Core is a hierarchy of six Functions with GOVERN at the centre of the wheel and the other five around it, which is a fair description of where policy sits. Map to it if it helps you answer questions. Do not write a policy that claims compliance with something nobody has implemented.
Review, version and the record of agreement
Give the policy an owner, a review date and a version number, and keep the record of who agreed to which version. The review date matters more than people expect: the common failure is not a bad policy but a policy last touched three years ago that still names a system the company no longer runs, which tells a reader exactly how seriously to take the rest of it.
Questions people ask about information security policy
How long should an information security policy be?
Two to four pages for a small organisation. If it is longer, most of what is in it is standard rather than policy and belongs one level down.
Do we need a separate acceptable use policy?
Usually yes, because it binds every employee while the security policy set is mostly read by the people who implement it. Acceptable use is the page people actually sign.
Who should own it?
A named person with the authority to enforce it. An unowned policy is not reviewed, and an unreviewed policy is the one that names a system you retired.