Marketing

Policy Structure

August 12, 2019

One of the more challenging aspects of creating policies for an organization is deciding which categories, to begin with. Maintaining 40–60 policies can overcomplicate an already complicated process. I found an article from February 2014 by David Lineman called How to Structure Information Security Policies that resonated with me. In this article, he offers advice on how which categories to start with. As I reviewed these with our CISO, we found that David’s approach did a good job of providing needed structure to our diverse (scattered) list of policies. I’d encourage you to read his article, and I’ve also provided the list of policies below:


IT Risk Management Policy (Risk Assessment) Security Program Policy (Policy, Planning, Personnel) Asset Management Policy (Inventory, Acceptable Use, Protection) Information Management Policy (Collection, Classification, Storage, Disposal) Third-Party Security Policy (Assessment, Contracts) Personnel Security Policy (Screening, training, termination) Access Control Policy (Systems, Accounts, Passwords) Network Security Policy (Firewalls, Structure, Wireless) Physical Security Policy(Visitors, IT Systems) Operations Management (Configuration, Change Control, Malware) Application Security Policy (Development, Testing) Security Incident Management Policy (Reporting, Response, Investigation) IT Business Continuity Policy (backup, Business Continuity) Security Monitoring Policy (Logging, Audit, Monitoring) Customer Privacy Policy Employee Data Privacy Policy


Another key takeaway from the article stresses the importance of keeping policy statements separate from procedure or standards statements. This is another firmly held belief at PolicyCo. Policies are all about intention in a generic sense, while procedures and standards are provided for specificity.


Policy — Files are backed up nightly. Procedure — A backup script runs on server A in /bin/backup.sh. It backs up database servers x, y and z. Joe Smith is responsible for its proper nightly operations and alerts go to noc@policyco.io if it fails.


The breakdown of Policy documents listed above is also convenient for separation of duties, ensuring the appropriate technical teams have access to the policies that affect their daily duties, particularly as it relates to technical vs. management teams. As with most things, there are many ways to organize information. I hope this has helped you in your decision-making process. Special thanks to Mr. Lineman and informationshield.com.

Marketing

Policy Structure

August 12, 2019

One of the more challenging aspects of creating policies for an organization is deciding which categories, to begin with. Maintaining 40–60 policies can overcomplicate an already complicated process. I found an article from February 2014 by David Lineman called How to Structure Information Security Policies that resonated with me. In this article, he offers advice on how which categories to start with. As I reviewed these with our CISO, we found that David’s approach did a good job of providing needed structure to our diverse (scattered) list of policies. I’d encourage you to read his article, and I’ve also provided the list of policies below:


IT Risk Management Policy (Risk Assessment) Security Program Policy (Policy, Planning, Personnel) Asset Management Policy (Inventory, Acceptable Use, Protection) Information Management Policy (Collection, Classification, Storage, Disposal) Third-Party Security Policy (Assessment, Contracts) Personnel Security Policy (Screening, training, termination) Access Control Policy (Systems, Accounts, Passwords) Network Security Policy (Firewalls, Structure, Wireless) Physical Security Policy(Visitors, IT Systems) Operations Management (Configuration, Change Control, Malware) Application Security Policy (Development, Testing) Security Incident Management Policy (Reporting, Response, Investigation) IT Business Continuity Policy (backup, Business Continuity) Security Monitoring Policy (Logging, Audit, Monitoring) Customer Privacy Policy Employee Data Privacy Policy


Another key takeaway from the article stresses the importance of keeping policy statements separate from procedure or standards statements. This is another firmly held belief at PolicyCo. Policies are all about intention in a generic sense, while procedures and standards are provided for specificity.


Policy — Files are backed up nightly. Procedure — A backup script runs on server A in /bin/backup.sh. It backs up database servers x, y and z. Joe Smith is responsible for its proper nightly operations and alerts go to noc@policyco.io if it fails.


The breakdown of Policy documents listed above is also convenient for separation of duties, ensuring the appropriate technical teams have access to the policies that affect their daily duties, particularly as it relates to technical vs. management teams. As with most things, there are many ways to organize information. I hope this has helped you in your decision-making process. Special thanks to Mr. Lineman and informationshield.com.

Marketing

Policy Structure

August 12, 2019

One of the more challenging aspects of creating policies for an organization is deciding which categories, to begin with. Maintaining 40–60 policies can overcomplicate an already complicated process. I found an article from February 2014 by David Lineman called How to Structure Information Security Policies that resonated with me. In this article, he offers advice on how which categories to start with. As I reviewed these with our CISO, we found that David’s approach did a good job of providing needed structure to our diverse (scattered) list of policies. I’d encourage you to read his article, and I’ve also provided the list of policies below:


IT Risk Management Policy (Risk Assessment) Security Program Policy (Policy, Planning, Personnel) Asset Management Policy (Inventory, Acceptable Use, Protection) Information Management Policy (Collection, Classification, Storage, Disposal) Third-Party Security Policy (Assessment, Contracts) Personnel Security Policy (Screening, training, termination) Access Control Policy (Systems, Accounts, Passwords) Network Security Policy (Firewalls, Structure, Wireless) Physical Security Policy(Visitors, IT Systems) Operations Management (Configuration, Change Control, Malware) Application Security Policy (Development, Testing) Security Incident Management Policy (Reporting, Response, Investigation) IT Business Continuity Policy (backup, Business Continuity) Security Monitoring Policy (Logging, Audit, Monitoring) Customer Privacy Policy Employee Data Privacy Policy


Another key takeaway from the article stresses the importance of keeping policy statements separate from procedure or standards statements. This is another firmly held belief at PolicyCo. Policies are all about intention in a generic sense, while procedures and standards are provided for specificity.


Policy — Files are backed up nightly. Procedure — A backup script runs on server A in /bin/backup.sh. It backs up database servers x, y and z. Joe Smith is responsible for its proper nightly operations and alerts go to noc@policyco.io if it fails.


The breakdown of Policy documents listed above is also convenient for separation of duties, ensuring the appropriate technical teams have access to the policies that affect their daily duties, particularly as it relates to technical vs. management teams. As with most things, there are many ways to organize information. I hope this has helped you in your decision-making process. Special thanks to Mr. Lineman and informationshield.com.

Bill Butler