Tag Archive | Risk

RSCA Tracking

trackingTools and Manual Tracking

As I mentioned in the RSCA Methodology overview, there are many tools on the market to help you perform tracking and reporting for regulatory compliance. I strongly suggest you invest in one of these tools and share it with your Internal Audit, SOx Audit and IT Compliance organizations. Having a single source for your tracking and reporting needs saves a great deal of time, and will cut down on the miscommunications between these organizations.

Most audit software companies have tools that will track all these data types and more. They also provide multi-user authenticated signon where project leaders and managers who own actions plans can update their the status of their assigned remediation items directly.

If however, your organization simply cannot afford these tools, you can perform the tracking and reporting through a manual process using MS Excel spreadsheets. If that’s the method you chose, there are specific data types to keep track of. Continue reading

The RSCA Process

processProcess Documentation

The Risk, Security & Compliance Assessment (RSCA) approach is used to evaluate the current state of security and compliance activities for SOx remediation initiatives. RSCA is a three-step methodology that covers Planning and Data Collection, Risk and Security Assessment, and Tracking and Reporting.

Each organization has their own Audit process to define the scope of an audit, the methodology for implementing that audit and how findings are reported. When findings fall into the realm of GRC, they should be handed off to a RSCA team for tracking and oversight for remediation.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).
Continue reading

RSCA Methodology

riskRisk, Security & Compliance Assessments

The RSCA approach is used to evaluate the current state of Security and Compliance activities for SOx remediation within a business. RSCA is a three-step methodology designed to manage and provide oversight for business risk and compliance. But keep in mind that neither SOx nor RSCA are designed to eliminate all risk. They are designed to ensure risks are known and either corrected or accepted.

To that end, RSCA addresses your companies governance through:

  1. Planning and Data Collection
  2. Risk and Security Assessment
  3. Tracking and Reporting

These steps have been implemented at many large corporations facing large remediation initiatives. But it’s a method that can be easily scaled to any size business. These steps help to ensure both your business and IT processes are being adhered to, identifies gaps or risks that need to be resolved, tracks those resolution efforts and provides a method of reporting through each chain of command necessary for Governance, Risk Management and Compliance (GRC) Assessments.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

Continue reading

Segregation Of Duties

sodRoles & Responsibilities

Segregation of Duties (SOD) is one of the biggest issues to hit IT organizations. Especially for those that have been in business for 40 years or more. Companies typically start out with open environments that relied on developers to implement new code straight into production. Many organizations have no change management or change control tools to help strengthen and secure their development, testing, implementation into production and subsequent maintenance changes and emergency fix processes.

Compliance initiatives have done away with the same ole procedures and now require organizations to maintain stronger and more restrictive control over their IT environments. Those that don’t make efforts for control, end up with significant deficiencies called out by their auditors. Continue reading

Writing IT Process Narratives

procnarrativeWhat is a process narrative?

A process narrative is a story or a guide to define what processes your IT group performs and how they perform those tasks. It’s not a high level document written from 10,000 feet up. But it’s also not a detailed installation guide. It’s a story of what you do.

A well written narrative reduces the misunderstandings that verbal communications can create when talking to auditors, coordinating backup/recovery tasks with other departments and even reference documents for your staff during emergencies when stress levels are high.

Written processes also help your team document little details that seem normal and common place to you, because you do the job. But when you’re talking about them and explaining them to someone else, you might leave those details out. It’s just part of what you do, you don’t think about it, you simply do it. But others may need to know those little things to fill in the gaps to their processes. Documenting those details also remove potential “Single Points Of Failure”. An important part of IT Governance!

There are additional benefits to documenting your process narratives. These documents can become training materials for new staff members. They can be procedure documents for those who perform backup support for out of the office staff. They can even help when you’re working on joint efforts with other IT support teams or business application development teams during problem solving tasks, or future enhancement efforts. Knowing a little about what your group does, can help others provide you information to support their efforts and avoid problems in the future.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

Getting Started
The first step to getting started is to decide what narratives your IT department needs. Sometimes the list can be obvious, Change control, Information Security, Network Operations are a few examples. The best idea is to review COBiT and determine what processes apply to your organization.

Step two is to decide who owns those processes. This isn’t always easy, but keep in mind you want subject matter experts writing these documents. If you’re writing a process to describe how upgrades and patches are applied to Solaris, you don’t want the change management team writing this. You want your Unix Systems Administration team writing the story of what they do and how they coordinate their efforts with application teams.

Next determine an outline or format so all your narratives have the same look and feel. One of the worst things you can do is give an auditor a stack of documentation to read that has no consistency. It’s worth it to create a format up front.

Writing the Narrative
Writing the narrative is just like writing a book. It has a beginning, middle and an end. It even has character development and a story line. Here are some basic sections to a process narrative.

  • The beginning.
    Describe the event that initialize the process represented in your narrative. Is it a new release of software or a new request to establish a web environment?
  • What, not how.
    One problem with techies is we like to talk about what we do. But we talk in the manner of doing it, the details behind the process. This isn’t an installation guide, it’s a high level story line. What are the steps you take once the process has been initiated?
  • List Resources
    Does your process employ other processes? If so, those should be listed in your document and referred to in your text. You shouldn’t duplicate or rewrite another narrative into this one. Narratives should be complete, but concise. As an example of this:
    – Once the patch has been tested and verified, implementation on all servers is scheduled through the standard Manage Change Process.
    – In your resource section, list the Change Management Process. AI.6.1 Manage Change (or whatever you call it).
  • Performance Roles.
    Who performs the processes in your narrative? Is it more than one person, is more than one group involved? Does a person in your group take on a different role for this narrative than their normal duties? For instance, you may say in your narrative:
    – The Unix System Administrator (USA) reviews the applications running on the production server and coordinates testing and upgrade procedures with those teams. In the Role section, you may define the application team member and their role in the process.
    – Application project manager – coordinates staff resources and assigns tasks to application team members to perform upgrade testing and validation.
    – Application team member – executes complete end to end testing of the application to ensure functionality performs effectively on the new upgraded environment.
  • Inputs and Outputs.
    For every process there is a series of inputs and outputs. These can be requests, vendor notifications, incident management tickets and so on. Additionally, each narrative has an output. What is the final result of the process and what documentation, forms, approvals and so on do you have to show the process was completed successfully.
  • Identify Controls.
    From your narrative, take the highlights and determine which steps are controls and which are key controls for this process. Some organizations prefer to highlight the controls in the narrative. Or you may prefer to list these Controls in a list at the end of the document. More on this in a moment.
  • Keeping a Change Log
    A change log should be kept at the end of each narrative. This is a log or change history of your narrative. What was changed, who changed it, when it was change and who signed off on the approval of the change. The writer and the person who approves the process should never be the same person. This isn’t the change of the process itself, though that can instigate a change. This is a change log of the narrative itself, if you took out a step because it’s no longer needed, or if you added a step that was missed or needs to be added because of a maintenance change from some other process; describe briefly what that change was and why. Keep it simple though.  Create a simple table for your change log and you’ll have all the information you need:

    No Description Updated By Date Approval Date

General Controls, Operational Controls and Key Controls
Identifying Controls
IT control objectives relate to the confidentiality, integrity, and availability of data and the overall management of the IT function of the business enterprise. IT controls are often described in two categories: IT general controls (ITGC) and IT application controls (ITAC).

IT controls that typically fall under the scope of a SOx 404 assessments can be identified in one of three ways.

  • Key Controls:
    Specific application (transaction processing) control procedures that focus on “key” processes (those that specifically address risks), not on the entire application. There are typically a few key controls within applications in each financial process. These deal with security of ids, passwords, financial accounts and transactions. What do you do to control security risks to your data.
    For instance: Passwords require a capital letter, at least 1 number, 1 special character and must be 8 characters long. Passwords must expire every 60 days and are automatically forced to change by what process (name the process).
  • IT General Controls
    These are processes that support the assertions that programs function as intended and that key financial reports are reliable. These are often infrastructure processes such as change control and security administration management. But they can be other things that you have put into place specific to your IT environment.
  • IT operations controls, which ensure that problems with processing are identified and corrected immediately and in a secured environment. This can be a reporting system to open a ticket, identifying priority and/or risk. It can be a migration, back up recover or software update process. It can be an internal weekly audit by a member of your staff and so on.

Completing Your Review
Initially, everyone writes their narrative in a perfect world nothing every goes wrong perspective. The “What happens when everything goes right” process. Once you have established the baseline of your narrative, go back and include the alternative processes. What happens when something goes wrong. How are those incidents handled and who signs off on them. This is an important step to finding holes in your narrative. It also helps you start the process of back up and recovery when something does go wrong.

Approving the Narrative
There are many ways to manage the narrative process. How that is handled will depend on how your organization has implemented regulatory compliance. At a high level, narratives for IT should be grouped into similar functionality and reviewed for completeness and consistency by group managers. But they should also be reviewed by department heads. Now in the real world, we know department heads don’t have the time themselves to read every narrative. And in some cases, those high level managers may not have the expertise to review such documents. Time to create a team of core experts.

For instance, all the narratives for all your infrastructure groups should be reviewed by an oversight committee made up from all the areas of a system infrastructure operation. Ensure that everyone has documented their process for managing change and incident management in the same way. You may want to standardize these paragraphs in each narrative as well. If your narratives are to be given to a Compliance group in your organization, I strongly suggest a representative of the compliance group participate on your review committee. It will save time later if additional changes need to be implemented from an overall IT perspective.

Once the narratives have been reviewed and approved by the process owner, they should be reviewed and approved by a senior manager. For instance, if all your infrastructure groups report to a Vice President, then that VP should review and signoff on all narratives. How that person completes that review is up to your organization. But this person will be held accountable when something goes wrong. So it’s worth it to understand what you’re signing off on. Narratives should then be compiled and given to your Compliance organization.

Narrative Timing
Your process narratives should be fairly stable documents once they’re written and established. But plan a review of your narrative on a bi-annual basis. This gives you the opportunity to update your narratives based on organizational changes, industry best practices, or technology changes. It also defines a good control for performing narrative oversight. Even if nothing changes, you’ve completed your due diligence to review the process and have signed off that everything is the same. In today’s world of fast development and changes in security, bi-annual is a good time-frame. I wouldn’t recommend annual reviews when security is concerned. But you may have processes that are necessary, but not impacted too much by changes in security. Those processes you can review annually.

Still Need Help?
Here’s a Narrative Template (MS Word) to help you get started. Keep in mind this is just a general starting point. As technology changes, so might your narrative template.

© 1997-2014 Springwolf, D.D., Ph.D., Springwolf's Kosmos. All Rights Reserved.
© 1997-2019 Springwolf, D.D., Ph.D., Springwolf’s Creations. All Rights Reserved.

Management Attestations

signatureAttesting To Compliance

An Attestation is management’s internal assessment and compliance with regulatory compliance certifications. These letters are also known as Compliance Certifications, GRC Agreements and the list goes on.

Typically only the CEO and CFO are required by law to sign an attestation. But more and more corporations are including the CIO in that requirement. Primarily because IT now plays such a critical role in ensuring the corporations data is secured and properly managed to retain reliable accounting systems.

Many CIOs become very uncomfortable in signing a corporate level attestation for their organization. How does the CIO know for sure that his direct staff is properly overseeing the IT components they manage? And how do those senior IT executives know that their directors and managers are giving proper attention and accountability to the processes they manage?

Because of this, many IT organizations are implementing an IT management wide Attestation to their compliance standards. From the lowest manager up, these attestations define the responsibility of each manager to adhere to corporate standards and compliance regulations. Each one roles up into a package for the next level manager to review and certify by signing their own attestation. Until finally, all of IT’s management has attested to the oversight of controls. And the CIO now feels like his/her back is covered.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

Continue reading

Implementing GRC In IT

sox404IT Governance

All IT organizations need to implement some type of Governance, Risk Management and Compliance (GRC) in their environment. No matter how big or small your organization might be, if your company has 1 password for something, you need oversight.

Oversight of risk has long been a best practice for any company that wants to remain competitive. A controlled environment provides an organization with stream lined processes, reusable procedures, better functioning systems, and typically under budget of expected costs.

This isn’t just some thing to do in order to meet federal, state or industry regulations. It’s about doing being a reliable business partner, a reputable company and an organization that can be trusted with integrity. All the things any size business needs to get an advantage in their local market.

See my IT Governance section for more information about IT Audit, and Governance, Risk Management & Compliance (GRC) and Risk, Security & Compliance Assessments (RSCA).

Continue reading

IT Governance, Risk Management & Compliance

soxWhat Is It?

Governance, Risk Management & Compliance (GRC) is an overall label for companies to implement best practices in their business and IT process to protect consumers and financial markets.

The concept began in the mid-to-late 1990s when several large publicly traded companies were found to have implemented shady practices to defraud customers, falsely report earnings and evade Federal Regulations.

As a result U.S. Senator Paul Sarbanes (D-MD) and U.S. Representative Michael G. Oxley (R-OH) sponsored a bill known as the ‘Public Company Accounting Reform and Investor Protection Act’ (in the Senate) and the ‘Corporate and Auditing Accountability and Responsibility Act’ (in the House). The bill has become affectionately known as the Sarbanes-Oxley Act or simply SOx and was signed into law in 2002.  Continue reading