https://www.linkedin.com/pulse/documentation-building-information-security-program-john-chislett/

 Documentation for Building an Information Security Program Your documentation should be layered into 4 categories for Audits and Security:

1)    Policy - Policies are formal statements produced and supported by senior management.

2)    Standard - Standards are rules that give formal policies support and direction.

3)    Process – Processes are overviews of Procedures for management to understand the steps for the purpose of monitoring/controlling and governance purposes

4)    Procedure - Procedures are detailed step-by-step instructions to end users
5)    User Guides (or Guidelines) - A 5th category should also be added, that being a User Guide. This is a more detailed version of the procedure, that can be changed edited by end-users and sent to management without approval and will assist in future versions of the above documentation.

Policies are formal statements produced and supported by senior management. They can be organization-wide, issue-specific, or system-specific. Your organization’s policies should reflect your objectives for your information security program—protecting information, risk management, and infrastructure security. Your policies should be like a building foundation; built to last and resistant to change or erosion.

·        Driven by business objectives and convey the amount of risk senior management is willing to accept.

·        Easily accessible and understood by the intended reader.

·        Created with the intent to be in place for several years and regularly reviewed with approved changes made as needed.

Standards are mandatory courses of action or rules that give formal policies support and direction. One of the more difficult parts of writing standards for an information security program is getting a company-wide consensus on what standards need to be in place. This can be a time-consuming process but is vital to the success of your information security program.

·       Used to indicate expected user behavior. For example, a consistent company email signature.

·       Might specify what hardware and software solutions are available and supported.

·       Compulsory and must be enforced to be effective (this also applies to policies).

Processes are a series of related tasks or methods that together turn inputs into outputs. They are typically intended for management and/or people who need to understand how a Procedure works, who is involved in making it work how it is monitored. The Process document should be approved, before the Procedure document. This ensures that the Controls, Monitoring, Governance and Risk have been identified and mitigated, by those that are responsible, before the Procedures are developed.

Procedures are detailed step-by-step instructions to achieve a given goal or mandate. They are typically intended for internal departments and should adhere to strict change control processes. Procedures can be developed as you go. If this is the route your organization chooses to take, it’s necessary to have comprehensive and consistent documentation of the procedures that you are developing.

·        Often act as the “cookbook” for staff to consult to accomplish a repeatable process.

·        Detailed enough and yet not too difficult that only a small group (or a single person) will understand.

·        Installing operating systems, performing a system backup, granting access rights to a system, and setting up new user accounts are all examples of procedures.

User Guides (or Guidelines) are recommendations to users when specific standards do not apply. User Guides are designed to streamline certain processes according to what the best practices are. User Guides, by nature, should be open to interpretation and do not need to be followed to the letter. 

·       Are more general vs. specific rules.

·        Provide flexibility for unforeseen circumstances.

·        Should NOT be confused with formal policy statements.

As you can see, there is a difference between policies, standards, processes, procedures, and user guides. Each has their place and fills a specific need.

https://www.linkedin.com/pulse/sox-sarbanes-oxley-audit-control-john-chislett/

Having to maintain your daily operations while also meeting the stringent requirements of a SOX audit can be very stressful.  

A review of a company's internal controls is often the largest component of a SOX compliance audit. Internal controls include all IT assets, including any computers, network hardware, and other electronic equipment that financial data passes through. A SOX IT audit will look at the following internal control items:

• IT security: Ensure that proper controls are in place to prevent data breaches and the tools to remediate incidents should they occur. Services and equipment that will monitor and protect your financial database.
• Access controls: This refers to both the physical and electronic controls that prevent unauthorized users from viewing sensitive financial information. This includes keeping servers and data centers in secure locations, implementing effective password controls, patching and hardening measures.
• Data backup: Maintain backup systems to protect sensitive data. Data centers containing backed-up data, including those stored off-site or by a third-party are also subject to the same SOX compliance requirements as those hosted on-site.
• Change management: This involves the IT department's process for adding new users and computers, updating and installing new software, and making any changes to databases and data infrastructure components. Records of what has changed, in addition to when it was changed and who changed it, need to be kept.

To document how you are implementing the internal controls you need to have:

A Monitoring and Control Section:

• A Monitoring section describes how the Process/Procedure is being tracked and what triggering mechanisms are in place to notify the responsible person or entity who overviews/owns this process
• A Control section specifies who is responsible for the integration into the company system. They identify whether a review is necessary and how to proceed with revisions if required 

Governance and Risk section:

• Who or what entity is responsible for the Process and/or Procedure and what Risks have been identified and how they are to be mitigated. 
• This is layered by who takes on the initial overview and then who owns the Process and/or Procedure.

The Process or Procedure steps

The Step/Action of the Process/Procedure which can be verified in the subsequent Process Flow

Your documentation should be layered into 4 categories for audit:

1) Policy - Policies are formal statements produced and supported by senior management.

2) Standard - Standards are rules that give formal policies support and direction.

3) Process – Processes are overviews of Procedures for management to understand the steps for the purpose of monitoring/controlling and governance purposes

4) Procedure - Procedures are detailed step-by-step instructions to end users

A 5th category should also be added, that being a User Guide. This is a more detailed version of the procedure, that can be changed edited by end-users and sent to management without approval and will assist in future versions of the above documentation. 

Having worked with each of the IT Operations Departments within Santander Bank during 3 major audits and then successfully passing all of those SOX audits, I can help unsure that your documentation is up to SOX standards and that your stakeholders and SMEs know what controls they are responsible for and that these are documented properly.

See the requirements in the link below:

• SOX Section 404 
• My LinkedIn Article

 Having created more than 500 Facilitator Guides, Tutorials and Quick Reference Guides (QRG) over the last 25 years, I have a very broad understanding of how to produce a wide range of instructional material to suit the needs of many types of audiences. 

My first step in the process is to perform a Needs Analysis that assesses what the Scope of the document should be:

• Does this need to be taught in a classroom?
• Is this something that could be taught in an eLearning?
• Would a QRG be sufficient?

Then there are other factors that need to be assessed before you can document

• Who is the audience?
• What are the tools needed to deliver the learning?
• Is the class going to be remote?

All of these factors and more need to be considered before you can successfully write the document(s) for your training. 

 I started my teaching/facilitating in Taiwan. I received my TEFL certificate from ELSI and subsequently taught there for 3 years. Since then:

• I taught hospitality English at Le Meridian in Phuket, Thailand 
• I was the instructional designer/director of services for a large English social club (ALE) in Taichung, Taiwan, which had over 12,000 members and over 30 teachers working for me
• I was the instructional designer/director of a business English company (WES) based in Taipei, Taiwan overseeing 60 customer locations and over 20 teachers
• I've taught Math and then Science for 2 private schools in Thailand (Assumption College and Sarasas Witaed)
• I taught CCNA to Network Engineers in Nashua, NH at John Mason Institute
• I taught Sales Force Automation to end users at  Pegasystems  in Cambridge, MA 
• I taught proprietary software, in class and virtually, to internal staff at Computershare, at multiple locations internationally and domestically.