Policy and Procedures – Security Compliance

All organizations have policies and procedures on how particular tasks and goals are established within the organization. The issue here is many of these are either word of mouth or haven’t been written down. This leads to having subjective policies and procedures that morph over time based off a loose understanding of the objective. Almost every regulated organization is being asked to have written policy and procedure to adhere with compliance that allows for a defined and objective method of handling policy and procedures within their organization. This creates a strategic framework for those that the policy and procedures are guiding. This being said, there are a few differences when it comes to policy and procedure.


A policy is more generic and outcome based that are meant to be more static than dynamic. Your policies are really there to define how particular areas of your business are being run. When dealing with a policy you’re defining in more high level and generic language the objective that you’re describing. This is purposely done because these governing policy are used to cover the lower level procedures. The policy answers the major operational and regulatory questions for the business to follow. These are the guiding principles that light the path for the lower level procedures.


With procedures you’re showing the steps required to fulfill the policies broad statement. With a procedure you’re getting down into a more focused view of what’s occurring. In most procedural documentation you’re aiming to answer the “how”, “who” and “when” of the policy. These documents are detailed oriented and describe how the policy is currently being completed. These are also more dynamic in nature. An example would be having a policy describing “Malware Protection” in a broad and general perspective, but a procedure on how you operate the malware protection with the vendor technology you’re utilizing. If you were to swamp vendors the procedure would most likely change, but it’s possible the policy would remain the same.

With these clearly written policy and procures it shows employees and regulators that there is an accepted way to perform business and security. This documentation is used as a reference to guide how users work in the organization. These are the guide rails as to what is expected and deemed appropriate. These documents should also be kept up to date as regularly as possible. As changes occur within the organization they need to be reflected within the documentation and signed off on. This practice is important due to the fact that guiding principles of the organization.

CCSI has helped write, review, and advise on policy and procedures for numerous organizations across multiple regulated environments. If you have questions or need assistance, please contact us to learn more.

Matthew Pascucci

Author Bio: Matthew Pascucci is a Security Architect, Privacy Advocate and Security Blogger. He holds multiple information security certificates and has had the opportunity to write and speak about cyber security for the past decade. He’s the founder of and can be contacted via his blog, on Twitter @matthewpascucci, or via email [email protected]

The post Policy and Procedures – Security Compliance appeared first on CCSI.

*** This is a Security Bloggers Network syndicated blog from CCSI authored by Matthew Pascucci. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)