2 added 448 characters in body
source | link

I currently work in the Information Security team at my company. I have been requested by company management to assist in reviewing and revising our current IT security policies. I am a trusted, respected member of the IT Security team, and previously management has requested me in assisting them to review the content of annual security training

Our current suite of policies are very comprehensive,covering topics from personnel security, Cloud security, physical security, logical access security...etc. However, only the IT security team and IT function in general is affected by a good portion of these policies. Examples:

  • Portions that talk about access administration is probably not relevant to a customer service representative working in a call center.

  • If you are not in IT, requirements for degaussing of backup media is probably not of use / concern.

My concern with everyone, regardless of their job role, having to acknowledge all policies is that they may pay less attention to the policies that actually pertain to them - e.g: storage of sensitive data for HR or social engineering safeguards for a CSR in the call center. Simply put, the amount of reading may turn people off, or they may just click through the policies simple to complete the tedious task, and not recognize the importance of what they are reading to the IT security mission of the company. We are an insurance company and work with sensitive customer credit card and private health information. We must also comply with PCI DSS, SOX 404, and state DOI regulations.

Based on feedback in my linked question, I am thinking of discussing with my management to leave common education requirements such as incident reporting, and acceptable use as untouched in the changes going forward. In this way, all users get a common foundation of the security requirements. Certain processes such as incident response can only work effectively with end user cooperation via timely reporting, so this seems like a no brainer.

Question

  • Is customizing corporate security policy acknowledgments based on what is actually relevant to a particular employee's job role a good idea?

  • If yes, what can be used to measure the applicability of security policies as they pertain any given job role?

I currently work in the Information Security team at my company. I have been requested by company management to assist in reviewing and revising our current IT security policies. I am a trusted, respected member of the IT Security team, and previously management has requested me in assisting them to review the content of annual security training

Our current suite of policies are very comprehensive,covering topics from personnel security, Cloud security, physical security, logical access security...etc. However, only the IT security team and IT function in general is affected by a good portion of these policies. Examples:

  • Portions that talk about access administration is probably not relevant to a customer service representative working in a call center.

  • If you are not in IT, requirements for degaussing of backup media is probably not of use / concern.

My concern with everyone, regardless of their job role, having to acknowledge all policies is that they may pay less attention to the policies that actually pertain to them - e.g: storage of sensitive data for HR or social engineering safeguards for a CSR in the call center. Simply put, the amount of reading may turn people off, or they may just click through the policies simple to complete the tedious task, and not recognize the importance of what they are reading to the IT security mission of the company. We are an insurance company and work with sensitive customer credit card and private health information. We must also comply with PCI DSS, SOX 404, and state DOI regulations.

Question

  • Is customizing corporate security policy acknowledgments based on what is actually relevant to a particular employee's job role a good idea?

  • If yes, what can be used to measure the applicability of security policies as they pertain any given job role?

I currently work in the Information Security team at my company. I have been requested by company management to assist in reviewing and revising our current IT security policies. I am a trusted, respected member of the IT Security team, and previously management has requested me in assisting them to review the content of annual security training

Our current suite of policies are very comprehensive,covering topics from personnel security, Cloud security, physical security, logical access security...etc. However, only the IT security team and IT function in general is affected by a good portion of these policies. Examples:

  • Portions that talk about access administration is probably not relevant to a customer service representative working in a call center.

  • If you are not in IT, requirements for degaussing of backup media is probably not of use / concern.

My concern with everyone, regardless of their job role, having to acknowledge all policies is that they may pay less attention to the policies that actually pertain to them - e.g: storage of sensitive data for HR or social engineering safeguards for a CSR in the call center. Simply put, the amount of reading may turn people off, or they may just click through the policies simple to complete the tedious task, and not recognize the importance of what they are reading to the IT security mission of the company. We are an insurance company and work with sensitive customer credit card and private health information. We must also comply with PCI DSS, SOX 404, and state DOI regulations.

Based on feedback in my linked question, I am thinking of discussing with my management to leave common education requirements such as incident reporting, and acceptable use as untouched in the changes going forward. In this way, all users get a common foundation of the security requirements. Certain processes such as incident response can only work effectively with end user cooperation via timely reporting, so this seems like a no brainer.

Question

  • Is customizing corporate security policy acknowledgments based on what is actually relevant to a particular employee's job role a good idea?

  • If yes, what can be used to measure the applicability of security policies as they pertain any given job role?

1
source | link

Should security policy acknowledgements in a company be customized for IT vs non IT users?

I currently work in the Information Security team at my company. I have been requested by company management to assist in reviewing and revising our current IT security policies. I am a trusted, respected member of the IT Security team, and previously management has requested me in assisting them to review the content of annual security training

Our current suite of policies are very comprehensive,covering topics from personnel security, Cloud security, physical security, logical access security...etc. However, only the IT security team and IT function in general is affected by a good portion of these policies. Examples:

  • Portions that talk about access administration is probably not relevant to a customer service representative working in a call center.

  • If you are not in IT, requirements for degaussing of backup media is probably not of use / concern.

My concern with everyone, regardless of their job role, having to acknowledge all policies is that they may pay less attention to the policies that actually pertain to them - e.g: storage of sensitive data for HR or social engineering safeguards for a CSR in the call center. Simply put, the amount of reading may turn people off, or they may just click through the policies simple to complete the tedious task, and not recognize the importance of what they are reading to the IT security mission of the company. We are an insurance company and work with sensitive customer credit card and private health information. We must also comply with PCI DSS, SOX 404, and state DOI regulations.

Question

  • Is customizing corporate security policy acknowledgments based on what is actually relevant to a particular employee's job role a good idea?

  • If yes, what can be used to measure the applicability of security policies as they pertain any given job role?