Chapter 24: Compliance, Governance, Risk, Audit Automation

24.1 Why.

Welcome to Chapter 24.

I am Ravindra Bagale.

Raju had no engineering degree. He had a folder named policies and a fear that DevSecOps had turned into homework. Guru-ji did not open the folder. He opened the pipeline log. "Governance is who may decide. Risk is which bad outcome you are buying down. Compliance is a named duty, such as PCI, SOC 2, or ISO, asking whether the control exists and works. Audit is the moment someone who was not in the room asks you to show it. Automation is how the show is a query, not a week of screenshots."

Raju waved at the folder. "The client wants ISO words."

"The client wants evidence," Guru-ji said. "Suppose we are Infosys and the client audit is on Thursday. Suppose we are Paytm or PayFast and card data has a fence called PCI. Suppose we are Amazon and a production change has no second person. Suppose we are Swiggy and a vendor kitchen app is in scope because it sees orders and nobody listed it. Suppose we are Netflix and an exception from last year still disables a control. Suppose we are BHIM UPI or WhatsApp-shaped systems and a privacy duty is treated as a banner instead of a retention setting. Suppose we are Zomato and the risk register says 'hacking' with no owner. Paperwork fog is a policy that does not name a control, a control that does not name a log, and a log nobody can query. Clear the fog. Keep the duty."

24.2 What.

Policy, standard, procedure, guideline. A policy is a decision: we protect customer data, we require a second factor, we do not ship secrets in Git. It is short and signed by someone who can enforce it. A standard is the measurable bar: admin sessions expire, trails stay on, images are signed. A procedure is the steps a human follows: how to rotate, how to respond, which you wrote in Chapter 23. A guideline is advice that is not a gate. If everything is a policy, nothing is enforceable. If everything is a guideline, the audit is a conversation. Label the document. Do not call a wish a control.

Risk registers without fog. A risk is a sentence: threat, asset, existing control, what is left over, owner, and the decision to reduce, accept, transfer, or avoid. "Cyber risk" is not a sentence. "A leaked CI token can deploy to the payment cluster, owner platform team, reduced by federation and a short role" is a sentence. Review the register when the architecture changes, not only on a birthday. Acceptance is allowed and must expire. An acceptance with no date is a shrug.

Control libraries. A control is a thing you can test. "Least privilege on the payment role" is tested by the deny you stored in Chapter 18. "MFA on humans" is tested by a directory query. "Runtime alert on a shell" is tested by the drill in Chapter 21. "Logs retained and undeletable by the app" is tested by Chapter 22. Build a small library. Each row in your notes, written as a line not a spreadsheet theatre, has an id, a statement, a test, and an owner. Map many duties to one control. Do not build a new control per paragraph of a framework.

ISO 27001, as awareness. ISO 27001 is a management system: scope, risk assessment, controls, internal audit, and improvement. The annex topics are ones you know: access, cryptography, operations, suppliers, incidents. A certificate is an audit of that system, not a spell on the product. In the lab, run the loop on one app. Do not rent an auditor to learn the loop.

SOC 2, as awareness. SOC 2 is an attestation report, common in SaaS deals, based on trust services criteria. Security is the usual core. Availability, confidentiality, processing integrity, and privacy can be in scope if you claim them. Auditors test whether controls operated over a period, not only whether a policy existed on one day. That is why screenshots from the night before the audit are a smell. A pipeline that enforced reviews all year is the report. You are not becoming a CPA in this chapter. You are learning to keep the evidence continuously so a future auditor is bored, which is the goal.

PCI DSS, as awareness. PCI DSS applies when you store, process, or transmit payment card data, and the scope follows the data. The duty is smaller when the card never touches your server because a specialist page takes it. It is larger when you keep numbers, logs of numbers, or a network path into the systems that do. Requirements you can feel in this course include firewalls and segments, least privilege, unique ids, MFA for admin, logging and time sync, vulnerability management, and change control. Paytm-shaped and PayFast-shaped designs should draw the cardholder boundary on purpose. A log that accidentally stores a full card number drags the log system into scope. That is an engineering bug, not a paperwork bug. Do not copy card numbers into the lab to "practice PCI." Practice with fake tokens and a drawn boundary.

HIPAA and GDPR, as awareness. HIPAA is a United States health-privacy regime. GDPR is a European data-protection law: purpose, minimization, rights, and security of processing. Many other laws rhyme. Collect less, know where it is, keep it only for the purpose, and show the measures. A banner is not a data map. In the lab, the order object does not include a field you do not need.

NIST CSF and the 800-series, as awareness. The Cybersecurity Framework groups outcomes as govern, identify, protect, detect, respond, and recover. You have been walking that list. The 800-series is a deeper menu. Pick one outcome, implement one control, test it. A framework is a map. A control is a road you paved.

CIS benchmarks. CIS-style benchmarks are the concrete settings Chapter 8 and Chapter 17 already leaned on: SSH flags, trail on, public buckets off. They make good automated tests. A benchmark fail is a ticket with a file path. A benchmark you mute globally is a policy you repealed in silence.

Control mapping. Take one real control in your lab: protected branch plus a second reviewer. Map it in one line to a duty. "Change control for SOC 2 and PCI." "Access control for ISO." The map stops people from building duplicate tools. It also stops an auditor from thinking the control is missing because the name in the policy does not match the name in the pipeline. Keep the map short. If a duty has no control, that is a gap, not a shame. Record it.

Evidence from CI and the cloud. Evidence is a query result with a time window. Pull requests that merged to the protected branch with a review. Cloud trail health. MFA enrollment. Role attachments. Runtime sensor version. Failed deploys that were supposed to fail. Export on a schedule to a bucket the operators cannot quietly edit. Store the query next to the export so you can rerun it. A screenshot of a console is evidence only of the minute it was taken. Prefer the API. Infosys-shaped audit weeks get shorter when Thursday's packet was generated on Wednesday by a job.

Continuous compliance and policy as code. A control that runs in CI every merge is continuous. Chapter 16's policy-as-code on infrastructure is the pattern. Add application and pipeline rules: no world-open storage, no admin role without MFA, no image without a digest pin, no exception file without an expiry. Break the build on the ones that are standards. Warn on the ones that are still guidelines. Compliance-as-code means the framework map is data, not a slide. When the standard changes, you change a test, not a poster.

Exceptions. An exception names the control, the reason, the compensating control, the owner, and the end date. A compensating control is a real second brake, such as a tighter network path while MFA is not yet possible on a legacy door. It is not the sentence "we accept the risk" alone. Expired exceptions re-open themselves as failures. Review them in the same pull request habit as code. Netflix-shaped speed still writes the date. Speed without a date is how the exception becomes the architecture.

Audit trails and retention. The trail of admin actions is itself a controlled system. Retain it for the period your duty names. Protect it from deletion. Time-sync it. You already built this in Chapter 22. Compliance adds the obligation to be able to hand a slice to an auditor without handing them the whole secret store. Redact. Scope the export. Record who exported it.

Separation of duties. The person who writes the change is not the only person who approves it, when the change can move money, identity, or production. The person who reviews access is not approving their own admin role. The pipeline identity cannot grant itself a new trust. Small teams fake this badly with shared accounts. Even a lab of one can simulate it with two roles and a rule that the apply role is not the author role. Write the exception if the team is too small, and revisit it when the team grows. Paytm-shaped payment changes deserve a second person more than a menu typo does. Match the duty to the blast radius.

Third parties and suppliers. Vendors, contractors, and libraries are in the system. A supplier assurance ask is a short questionnaire plus evidence: how they authenticate, how they log, how they notify you of an incident, how long they keep your data. Your SBOM and Chapter 13's provenance answer the library half. The contract answers the company half. Swiggy-shaped and Zomato-shaped partners who call webhooks are suppliers of events. Chapter 20's signature check is a supplier control. Reassess when the scope changes, not only when procurement says the year turned.

Attestations and procurement. Buyers ask for SOC reports, ISO certificates, and secure-development letters. Those are summaries. Say only what you can show. Do not claim every build is scanned if the scanner fails open. When you are the buyer, ask for a query you recognize, not for a logo.

A lab evidence job. Own lab only.

nightly:
  export protected-branch reviews for 1 day
  export cloud admin events for 1 day
  export MFA-disabled users
  fail the job if a new admin user has no second factor
  write the files to an evidence bucket with delete denied

That job is more compliance than a rewritten policy PDF. The PDF can be one page that points at the job.

24.3 How.

1. Write "own lab only" and one policy sentence: what your lab app must protect.
2. Write two standards that are testable, such as MFA for humans and no unreviewed merge to the protected branch.
3. Point each standard at a procedure you already have, even if the procedure is five lines.
4. Write three risks as sentences with owners. Accept one with an end date.
5. List five controls you already operate from earlier chapters.
6. Give each control an id, a test, and an owner.
7. Map one control to a PCI-shaped idea, one to a SOC 2-shaped idea, and one to an ISO-shaped idea, in a single line each.
8. Draw the lab data boundary. Mark that card numbers and real personal data are out of the lab.
9. Confirm logs do not contain secrets or fake card numbers that look real.
10. Add a CI check that fails if the protected branch allows a solo merge, or document the small-team exception with a date.
11. Add a check that fails if cloud audit is off.
12. Add a check that lists human users without MFA.
13. Export one day of those results to an evidence location the app cannot delete.
14. Store the query beside the export.
15. Schedule the export. Run it twice to prove it is not a hero script.
16. Write one exception with a compensating control and an expiry. Date it so it will expire during your exercise.
17. Show that the expired exception fails the check or raises a ticket.
18. Separate author and approver roles in the lab, even if you switch hats on purpose.
19. List one supplier or one library. Write the one question you would ask, and answer it from your SBOM or your webhook verify.
20. Redact a sample evidence export and note who is allowed to pull it.
21. Write a six-line attestation you can truthfully say about the lab. Delete any line you cannot show.
22. Time-sync note: label evidence times in Asia/Kolkata when you show them to a person.
23. Put the map, the risks, and the job link in one README page. Stop there. Do not write a novel.
24. Review the page with a friend or a future you. If they cannot find the query, the page failed.
25. Stop. No collection of real card data, no fake audit letters, no compliance scans of companies you do not own.

24.4 A real public incident.

Name. British Airways personal-data breach and the ICO penalty.

Date. The UK Information Commissioner's Office issued a monetary penalty notice to British Airways on 16 October 2020, fining the airline £20 million. The notice concerns a 2018 cyber incident. The ICO has publicly described the breach as affecting more than 400,000 customers. British Airways notified the ICO in September 2018.

Source. Information Commissioner's Office monetary penalty notice against British Airways, 16 October 2020, and the ICO's public announcement of the £20 million fine for the 2018 breach. This chapter uses those public documents for the duty and the outcome. It does not describe the attack path or how website code was changed.

What happened. Attackers compromised British Airways systems in 2018 and customer personal data, including payment card data, was taken. BA reported the breach to the ICO. In October 2020 the ICO concluded that BA had failed to put appropriate security measures in place and imposed a £20 million penalty under the GDPR, reduced from an earlier notice of intent that had proposed a larger figure. The public lesson for this chapter is not a tour of the intrusion. It is that a famous brand, a payment flow, and a stack of expected controls still produced a regulatory finding that security measures were not appropriate. Logging, access control, and change control are duties you can test every day. A policy that says cardholder data is protected, without a query that shows who changed the payment path and whether unexpected data left the site, is the fog. PCI-shaped scope and GDPR-shaped security-of-processing ask the same engineering question: where is the data, who can change the system that touches it, and which log proves the control ran during the period, not the night before the letter.

How to stop.

1. Contain the site and the systems that handle payment or personal data. Preserve logs before you patch over them.
2. Rotate credentials and keys. Remove the unauthorized change from the serving path by rebuilding from a trusted version.
3. Notify the supervisory authority and the people affected on the legal clock, with facts you can support.
4. Stop collecting new card data into any log or debug store that was never meant to hold it.
5. Stand up the evidence export so the next question from a regulator is a query.

How to prevent it again.

1. Draw the cardholder and personal-data boundary. Shrink it. Do not log secrets or full card numbers.
2. Change control with a second person and a pipeline record, mapped to the duty in one line.
3. Detections on unexpected changes to the payment path and on unusual outbound data, owned and tested.
4. Exceptions that expire, and attestations you can rerun.
5. A retention and access story for the audit trail itself.
6. Practice the evidence job on a lab with fake data. Do not probe airline or payment sites, and do not collect real card numbers to prove a point.

This is for learning only, and only inside a system you are allowed to test.

24.5 A simple picture.

A duty such as PCI, SOC 2, or ISO sits on the left. A control you already run sits in the middle. A scheduled query drops evidence into a store the app cannot delete. An exception has a date or it falls off the picture.

24.6 A short animation.

A control stamp appears only when the query returns proof. A policy page with no query stays blank. The stamp fades when the exception date passes.

24.7 Conclusion.

Raju's policy folder was one page. The nightly job had already written yesterday's evidence. Guru-ji closed the Magical Code Library notebook for this stretch of the road. "You can show MFA, a reviewed change, a trail, a runtime alert, and a response drill without inventing a new language for each framework. When later chapters open, they can pave this into a platform. Until they do, keep the query, keep the owner, keep the lab yours."

• A policy decides. A standard is testable. A procedure is the runbook. A guideline is not a gate.
• PCI, SOC 2, and ISO are labels on controls you can already query.
• Evidence is a scheduled export, not a screenshot collected in fear.
• Exceptions expire. Attestations say only what the query shows.
• The ICO's £20 million penalty against British Airways, 16 October 2020, is the duty without the working control.
• Own lab only.

END OF CHAPTER 24 MASTER CLASS