Building effective and accurate policies is required for ensuring compliance and successful process implementation and management within your organization. At Secureframe, we provide templates that can be used to get started. These templates should be tailored to fit your needs and organizational processes. This guide offers best practices and recommendations for building and editing Secureframe’s templated policies to efficiently implement what’s best for your organization.

Key Principles

• Completeness and Accuracy: The most important thing when it comes to policies is that they are complete and accurate. Policies should accurately reflect the operations and responsibilities of your organization. Be mindful to fill in any placeholders in the policy templates with information specific to your organization.
  • If there is a statement in the template that your organization is not expected to perform due to the nature of your environment and service then remove that statement since it is not an accurate reflection of your environment. Secureframe suggests not removing whole sections to ensure requirements are met, but instead stating how your organization is planning to meet the intent of the section or stating why that section is not applicable.
• Policy Ownership: Assign policy ownership to individuals or teams you deem most responsible for ensuring the policy’s implementation and ongoing management. The owner should be accountable for the policy’s implementation and ongoing effectiveness & adherence.
• Customizable Policies: The policies provided by Secureframe contain industry best practices. You are advised to edit them as necessary to reflect your organization's environment and services. Again, we recommend not removing entire sections, as this may leave gaps in your compliance.
  • If you choose not to make any edits, it’s important to ensure that you fully implement the controls outlined in the policy as auditors will refer to your policies when assessing if controls are in place and how they are maintained. The policies will act as the source of truth for the auditors during testing so it’s important everything is aligned.
• Support from Secureframe: We are always here to help and provide guidance related to policy questions, however our support cannot make policy edits for you. If you need help with drafting and customizing the policies, we have great partners we are more than happy to refer you to.
  The more specific your questions, the easier it is for us to offer guidance and ensure your policies are appropriately tailored.

Editing Policy language

Responsibility for Edits: Any brackets, placeholders, or highlights in the policies are left intentionally open-ended to be updated with what best suits your organization. The most important consideration is to ensure the information is complete and accurate. For example, the name of the responsible team or system can vary depending on your setup—what matters is that it aligns with your organization.

Example A: Editing the ‘Quarterly Access Review’ section of the Access Control and Termination Policy

Template: 

A team manager must review, audit, and document user accounts and associated privileges of at least high-risk and critical systems at least quarterly to ensure that access is restricted appropriately.

Edited version:

Each quarter, the system administrators must review and validate user access to high-risk and critical systems. Access is reviewed via Secureframe and maintained within the access review spreadsheet. This process involves verifying that only authorized personnel have the appropriate privileges to update and revoke access as needed. Full documentation of the review is required to confirm ongoing access control compliance. The responsible manager will then sign off and share the review with relevant leadership, security, and IT personnel. 

Example B: Editing the ‘Approval and Implementation’ section of the ‘Change Management Policy’

Template:
Once the new release is ready for deployment and the appropriate documentation is in place, the new release must be approved and reviewed by the appropriate product owner prior to being pushed to the production environment.
The ability to push changes to production at {{company_name}} must be restricted to a limited set of authorized team members, and the engineer responsible for coding the change should not also be responsible for pushing the change to production, unless there is prior approval of the exception by management.

Edited version:
Once a new release is ready, it must undergo a formal peer review using GitLab Merge, ensuring that at least two engineers, including one from a different team, review the code and associated documentation. After peer review, the release should be sent for final approval to a cross-functional change advisory board (CAB), which may include members from product, security, and operations teams, rather than just the product owner. Once approved, changes are deployed using a CI/CD pipeline within GitLab CI, ensuring that only authorized personnel can trigger deployments to the production environment. To ensure segregation of duties, the engineer who coded the change is not permitted to push it to production. In exceptional cases where this is unavoidable, written approval from a senior manager must be obtained, and the deployment must be logged and audited for compliance with SOC 2/NIST requirements.

In both of the examples above there are changes to the template made, edited to more accurately reflect how an organization has defined and implemented their security controls.

If Federal frameworks are applicable:

• Commercial/Federal Policies: Commercial policies (e.g., policies relevant to SOC 2 or ISO 27001) should be sufficient for federal requirements (e.g., NIST 800-53, CMMC, etc.) because these policies often overlap in core security and compliance standards. However, if there are specific differences between the federal and commercial aspects of your business, these distinctions must be clearly noted in the policies to ensure clarity and compliance.

Federal Procedures: Federal frameworks (e.g. NIST 800-53, CMMC, etc.) typically require formal procedures that outline how policies and their processes are implemented. This is often not a requirement for commercial frameworks, where policies alone may be sufficient. For federal compliance, make sure that your policies include the related procedures to meet federal requirements.

Frequently Asked Questions (FAQ)

Does Secureframe have vCISOs that can support “hands-on-keyboard” assistance?

• Yes, our vCISO partners are available to provide support, including hands-on guidance, to help you craft and finalize policies. Reach out to us with specific needs, and we can help guide the process.

Are all policies required for SOC 2?

• Most policies provided by Secureframe are necessary for SOC 2 compliance, but certain ones—like physical security, privacy, and processing integrity policies for SOC 2 compliance—are optional depending on the nature of your business and scope of your SOC 2 trust service criteria. Make sure to review the policies carefully to determine what is necessary for your organization.

Do I have all the policies I need for the framework I am trying to achieve? 

• Yes. Secureframe provides all the policy templates needed for each of the frameworks that you purchased. If you feel something is missing please reach out to the Secureframe team and they can provide a template or help find an ideal solution to your question. 

What happens if I don’t follow the policies?

• If your organization doesn’t adhere to the policies, it will likely result in compliance findings during your audits or assessments. This could and will lead to penalties, extra remediation work, and/or even non-compliance with regulatory requirements, laws, regulations, etc.

Should I make edits to the policies, or can I use them as provided?

• The most important thing is to ensure the policies are complete and accurate. All policies must be reviewed and edited to reflect how your environment meets each specified process. When making edits, focus on keeping the core structure intact and ensuring completeness and accuracy with your implemented processes.

What are the differences between the policies and procedures? Are procedures meant to be completed from scratch?

• Procedures are different from policies and are required to be documented for frameworks such asNIST 800-53, NIST 800-171, CMMC, TX-RAMP, etc. Policies define the requirements for an organization, whereas procedures document the specific processes in place to meet those requirements.

If you have additional questions or need more specific guidance, please feel free to reach out to Secureframe’s support team. We are happy to help and support you throughout your compliance journey!