Should I put all the detail policy inside of the single information security policy, or put their link in the policy only

You should not put all the detailed policies and procedures inside a single information security policy document. Instead, you should:

• Keep the main information security policy as a high-level, strategic document that defines the organization's security objectives, principles, and responsibilities.
• Link to (or reference) supporting standards, procedures, and detailed policies (such as access control, encryption, change management, etc.) from the main policy, rather than embedding all the details within it.

Why Link, Not Embed All Details?

1. Best Practice and Clarity

• Leading frameworks (like NIST, ISO, PCI DSS) and industry experts recommend a hierarchical structure:
  • Policy (high-level "what" and "why")
  • Standards (specific "what" and "who")
  • Procedures/Guidelines (detailed "how")
• This makes it easier for different audiences to find what they need without being overwhelmed by irrelevant detail.

2. Easier Updates and Maintenance

• Technical and procedural details change far more frequently than high-level policies.
• If you embed all details in one document, every change (e.g., to a firewall rule process or encryption protocol) forces a full policy review and re-approval.
• Linking allows you to update standards/procedures independently, keeping the main policy stable and current.

3. Audience Appropriateness

• Executives, auditors, and general staff need to know the rules and responsibilities—not the step-by-step technical processes.
• IT, security, and operations teams need detailed procedures, which they can access via referenced documents.

4. Compliance and Audit Readiness

• Auditors expect to see a clear policy hierarchy: a top-level policy with references to supporting documents.
• This structure demonstrates that you have both strategic oversight and operational detail, and makes it easier to show evidence of compliance.

5. Reduces Confusion and Overlap

• Separate documents for each topic (e.g., access control, incident response, encryption) reduce conflicting language and make responsibilities clear.

What Should the Main Policy Contain?

• Purpose and scope
• Security objectives and principles
• Roles and responsibilities
• High-level requirements ("must"/"shall" statements)
• Reference to supporting standards, procedures, and guidelines (with links or document numbers)
• Review and maintenance process

Example:

"All employees must use strong passwords as described in the [Password Standard]." "All network changes must follow the [Change Management Procedure]."

What Should Be in Linked Documents?

• Detailed technical controls (e.g., firewall rules, encryption algorithms)
• Step-by-step procedures (e.g., how to provision a user, how to onboard a server)
• Technical standards and configuration baselines
• Forms, checklists, and templates

Summary Table

Document Type	Content Focus	Audience	Update Frequency
Information Security Policy	High-level "what/why"	All staff, management, auditors	Low
Standards/Procedures	Detailed "what/how/who"	IT, security, operations	Moderate/High

Conclusion

Keep your main information security policy high-level and reference/link to detailed standards and procedures in separate documents. This is the best practice for clarity, maintainability, compliance, and audience appropriateness.