As an IT auditor at my workplace, focusing on short  - term solutions seems to be the preferred way rather than doing a root cause analysis (RCA) and letting the results guide further action.

For example, change management has been consistently weak from past audit results. When a change request has insufficient evidence of following the company SDLC, I most often get retroactive approvals on the spot.

The SDLC process is not burdensome and seems reasonable. Standard phases of progress such as Requirements definition > Development > QA > User Testing > Production release is defined and documented with upper management support. There are separate, but interactive, teams on each phase of the SDLC such as development, QA...etc. Tools for tasks such as source code version control / release control and code reviews are in place and being actively used.

Such carefree response in the example casts doubt on the effectiveness of the SDLC process. Focusing on short term, band-aid fixes is convenient but does not solve historical trend of control weakness. It is also an missed opportunity for process maturity.

Responding to some of the answers here that this impractical or misguided, I like to see our role as more of an advisor rather than enforcer. Basically, what can we do better than where we are now? Rather than asking, who is to blame, let's find out where the process is deficient so we improve the next time.

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?

As an IT auditor at my workplace, focusing on short-term solutions seems to be the preferred way rather than doing a root cause analysis (RCA) and letting the results guide further action.

For example, change management has been consistently weak from past audit results. When a change request has insufficient evidence of following the company Software development life cycle (SDLC), I most often get retroactive approvals on the spot.

The SDLC process is not burdensome and seems reasonable. Standard phases of progress such as Requirements definition > Development > QA > User Testing > Production release is defined and documented with upper management support. There are separate, but interactive, teams on each phase of the SDLC such as development, QA...etc. Tools for tasks such as source code version control / release control and code reviews are in place and being actively used.

Such carefree response in the example casts doubt on the effectiveness of the SDLC process. Focusing on short term, band-aid fixes is convenient but does not solve historical trend of control weakness. It is also an missed opportunity for process maturity.

Responding to some of the answers here that this impractical or misguided, I like to see our role as more of an advisor rather than enforcer. Basically, what can we do better than where we are now? Rather than asking, who is to blame, let's find out where the process is deficient so we improve the next time.

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?

As an IT auditor at my workplace, focusing on short - term solutions seems to be the preferred way rather than doing a root cause analysis (RCA) and letting the results guide further action.

For example, change management has been consistently weak from past audit results. When a change request has insufficient evidence of following the company SDLC, I most often get retroactive approvals on the spot.

The SDLC process is not burdensome and seems reasonable. Standard phases of progress such as Requirements definition > Development > QA > User Testing > Production release is defined and documented with upper management support. There are separate, but interactive, teams on each phase of the SDLC such as development, QA...etc. Tools for tasks such as source code version control / release control and code reviews are in place and being actively used.

Such carefree response in the example casts doubt on the effectiveness of the SDLC process. Focusing on short term, band-aid fixes is convenient but does not solve historical trend of control weakness. It is also an missed opportunity for process maturity.

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?

As an IT auditor at my workplace, focusing on short - term solutions seems to be the preferred way rather than doing a root cause analysis (RCA) and letting the results guide further action.

For example, change management has been consistently weak from past audit results. When a change request has insufficient evidence of following the company SDLC, I most often get retroactive approvals on the spot.

The SDLC process is not burdensome and seems reasonable. Standard phases of progress such as Requirements definition > Development > QA > User Testing > Production release is defined and documented with upper management support. There are separate, but interactive, teams on each phase of the SDLC such as development, QA...etc. Tools for tasks such as source code version control / release control and code reviews are in place and being actively used.

Such carefree response in the example casts doubt on the effectiveness of the SDLC process. Focusing on short term, band-aid fixes is convenient but does not solve historical trend of control weakness. It is also an missed opportunity for process maturity.

Responding to some of the answers here that this impractical or misguided, I like to see our role as more of an advisor rather than enforcer. Basically, what can we do better than where we are now? Rather than asking, who is to blame, let's find out where the process is deficient so we improve the next time.

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?