Skip to main content

Audit and compliance

This section outlines key application audit requirements and compliance practices within a z/OS® DevOps workflow.

What is an audit?​

"An Information Technology audit is the examination and evaluation of an organization's information technology infrastructure, applications, data use and management, policies, procedures, and operational processes against recognized standards or established policies. Audits evaluate if the controls to protect information technology assets ensure integrity and are aligned with organizational goals and objectives."
— Definition provided by Harvard University

Application audit requirements​

The above definition encompasses all aspects of an audit. For our purposes, we will focus on what an auditor looks for after an application development cycle.

Two key areas of an application audit are access controls and the software development lifecycle. The general requirements for these areas are described in the following subsections.

Access controls​

Auditors ensure teams are authorized to work on a given application. Access control layers include permitting:

  • Development team members to make changes to an application
  • Peers to review and approve changes
  • Team leads to give final approval and integrate changes
  • Administrators to have general oversight and optionally approve releases to upper environments
  • Auditors to have general access for oversight and compliance review

Software development lifecycle​

Auditors review software development compliance along the following key areas:

  • Release management
    Assess the controls around changes, ensuring they are documented, tested, reviewed, and approved.

  • Patch management
    Ensure patches (hot fixes) are applied to address vulnerabilities or outages.

  • Separation of duties
    Prevent errors and fraud by ensuring no single individual has control over all aspects of the development process.

  • Traceability and reporting
    Ensure secured and immutable compliance evidence (audit trails) like logs and reports across the development lifecycle that include:

    • What was changed and why
    • When it was changed
    • Who made the change
    • Who reviewed and approved it
    • How artifacts are tracked from development to production

  • Records retention
    In some cases, audit report retention of up to 7 years is required as defined under the Sarbanes-Oxley Act (SOX) in the USA. Other countries may have different requirements.

Application audit compliance practices​

A core component of audit compliance is the rules that define and enforce the activities that users have within the development lifecycle.

All major DevOps service providers and tools include access controls, typically enforced by Role-Based Access Control (RBAC) policies under the Lightweight Directory Access Protocol (LDAP). These access controls can be extended to integrate with z/OS security facilities such as Resource Access Control Facility (RACF®).

Examples and key practices that administrators can implement to comply with the audit requirements outlined above include:

  • Source code access:
    Using GitHub as an example Git provider, RBAC is implemented through a system of permissions and roles that manage individual user and team access to repositories and other organization resources.

  • Git branch protection:
    Administrators define access rules to prevent unauthorized updates to, for example, production-level branches. For more details on branching models and protection, see the IBM Z® DevOps Acceleration Program's recommended Git branching model for mainframe development.

  • Separation of duties:
    Separation of Duties (SoD) establishes a broad set of access controls through various practices and tools:

    • RBAC is used to enforce SoD by assigning different roles and permissions to different users. Each role has specific responsibilities and limitations, ensuring that no single person can perform all critical tasks.
    • Workflow automation tools provide features that enforce SoD by requiring multiple approvals and checks at different stages of the development lifecycle.
      • Git pull requests: Developers submit pull requests for code changes, which must be reviewed and approved by one or more peers before merging.
      • Approval gates: Continuous integration/continuous delivery (CI/CD) pipelines include approval gates where designated individuals must approve a build and release.
      • Trusted users: In z/OS, CI/CD processes run under a privileged account, also known as a "protected account" in RACF. For example, this account is authorized to run automated builds of any mainframe application using tools like IBM® Dependency Based Build or to release any package from development up to production using tools like IBM Wazi Deploy.

  • Traceability and reporting:

    • Git history: Track who made changes, when, and what was changed.
    • CI pipeline logs: Logs from CI tools like Azure DevOps CI, which show what was built, by whom, and where the output artifacts were stored.
    • CD pipeline logs: Logs from CD tools like IBM Wazi Deploy, showing where artifacts were downloaded and deployed on a z/OS host.

  • Records retention:
    DevOps administrators ensure that logs and reports are protected and retained based on the organization's policies.

Further reading​

While this page highlights key aspects of software development audit requirements, there are many more topics to consider. DevOps tooling vendors may also have their own specific documentation on implementing compliance using their products. The following examples are vendor-specific references with further details:

Last updated on

On this page