Introduction

Under ITIL Organizational Change Management, system and program changes should be standardized, documented, tested, and formally approved before being placed into production. This audit evaluated whether Gee Mail's production deployments followed two Change Control guidelines:

1. Changes are approved by a manager (not a developer).
2. Approvals occur before deployment.

Methodology

Audit objectives were to confirm testing/approval timing and segregation of duties for production deployments. Using the provided Git log, testing log, and IT employee list, the following tests were performed:

• Matched each production commit (SHA1) to a test approval record using the application hash.
• Compared test approval timestamp to production deployment timestamp to identify any post-deployment testing.
• Mapped each tester employee ID to job title to verify that approvals were made by a manager.
• Flagged self-testing where the author and tester were the same person.
• Aggregated results to compute compliance rates and identify exceptions.

Results

The sample contained 43 production deployments. All deployments had a matching test record and all tests were approved before deployment (0 post-deployment approvals). The primary control gap was segregation of duties: 3 deployments (7.0%) were approved by developers, and all of these were self-tests. Typical approval lead time was about 23.3 hours before deployment, with a range of 19.2 to 26.4 hours.

The managers are Heidi Pound, Bethel Hindman, Wyatt Tubbs, and Rachelle Munsterman.

From the Source Data

The numbers above are reproducible directly from SecurityDataAnalysis.xlsx. The workbook contains three relevant sheets — employeelist, gitlog, and testinglog. Aggregating them produces the following breakdowns.

Commits by author

Counting rows in the gitlog sheet by the Name column:

Test approvals by tester

Counting rows in the testinglog sheet by tester, after joining EmployeeID to employeelist:

The three developer-approved rows in this table are the same three exceptions surfaced in Table 2 above — the segregation of duties failures are isolated to two developers (Jessica Pettie and Vita Harryman) who also happen to be the only authors in the sample.

Workforce composition

From the employeelist sheet — useful context when interpreting how concentrated approval responsibility is at Gee Mail:

Risk Analysis

While timing controls were effective (100% of approvals occurred pre-deployment), the segregation-of-duties control failed for 3 deployments. Developer self-approval increases the likelihood that defects, insecure code, or unauthorized changes reach production without independent review.

Even a low exception rate can be high impact because a single unreviewed change may introduce data exposure, service interruption, or noncompliance findings during external audits.

Recommendations

• Enforce manager-only approval: require a manager role for test sign-off in the testing workflow and block deployments without it.
• Prevent self-testing: require tester employee ID to differ from author employee ID for standard changes.
• Implement an emergency change path: allow expedited deployment only with documented emergency reason and mandatory post-implementation manager review within 24 hours.
• Add automated controls that verify (a) test approval exists, (b) approval timestamp precedes deployment, and (c) approver role is manager.
• Monitor and report: weekly exception report to management covering any developer-approved or post-deploy-tested changes.