From frameworks and laws to engineering controls

#Why it matters

Compliance appeared in 78% of the Cybersecurity Engineer job descriptions we read. Startups selling to enterprises need SOC 2 or ISO 27001; anyone handling card data needs PCI DSS; anyone handling personal data of people in India is covered by the Digital Personal Data Protection Act. Engineers turn these documents into configurations, processes and evidence.

#The concept

All of them come down to a familiar set of engineering controls: access control and least privilege, encryption, logging and monitoring, vulnerability management, secure development, backups, incident response, vendor management, and data minimisation and retention.

Controls are what you actually do. Evidence is how you prove it: configurations, logs, tickets, test results. A single control usually satisfies several frameworks at once, which is why teams keep one control list mapped to many frameworks.

#Worked example: one control list, many frameworks

A lean control register kept in the repository, readable by engineers and auditors:

- id: CTL-01
  control: Production data stores are encrypted at rest and in transit
  frameworks:
    iso27001: [A.8.24]           # use of cryptography
    soc2: [CC6.1, CC6.7]
    pci_dss: ["3.5", "4.2"]
  owner: platform-team
  evidence: automated check of storage and database encryption settings, daily
- id: CTL-02
  control: Access to production requires SSO with MFA and is reviewed quarterly
  frameworks:
    iso27001: [A.5.15, A.5.18, A.8.5]
    soc2: [CC6.1, CC6.2, CC6.3]
    pci_dss: ["7.2", "8.4"]
  owner: security-team
  evidence: identity provider configuration export and signed quarterly review tickets
- id: CTL-03
  control: Security incidents are triaged within 1 hour and reportable incidents sent to CERT-In within 6 hours
  frameworks:
    iso27001: [A.5.24, A.5.26]
    soc2: [CC7.3, CC7.4]
    india: [CERT-In directions 2022]
  owner: security-team
  evidence: incident tickets with timestamps, annual tabletop exercise report

"""Which frameworks does each owner support, and which controls lack automated evidence?"""
import yaml

controls = yaml.safe_load(open("controls.yml"))
for control in controls:
    frameworks = ", ".join(control["frameworks"])
    automated = "automated" in control["evidence"]
    print(f'{control["id"]} {control["owner"]:14} {frameworks:30} automated evidence: {automated}')

CTL-01 platform-team  iso27001, soc2, pci_dss        automated evidence: True
CTL-02 security-team  iso27001, soc2, pci_dss        automated evidence: False
CTL-03 security-team  iso27001, soc2, india          automated evidence: False

Mapping identifiers change between versions of a standard; confirm them against the current edition before an audit. The structure, one control mapped to many frameworks, is what matters.

#Common mistakes

• Treating compliance as security. A certificate proves controls existed during the audit window; it does not stop attacks. Build real security and let compliance evidence follow.

• Separate spreadsheets per framework. Controls drift apart. Keep one register mapped to all.

• Evidence by screenshot. It is slow and goes stale. Automate where you can (see the compliance as code module).

• Ignoring Indian requirements in teams that copy a US or EU playbook. CERT-In timelines and DPDP obligations are specific.

#Interview angle

"What is the difference between ISO 27001 and SOC 2?" ISO 27001 certifies a management system against a standard; SOC 2 is an auditor's report on controls against the Trust Services Criteria, common with US customers. Then say how you would implement one control and produce evidence for both.

#Practice task

1. Add three controls to the register: backups tested quarterly, vulnerability scanning with patch deadlines, and logs kept for 180 days.

2. For one control, write exactly what evidence an auditor would ask for and how you would produce it automatically.

3. Read the DPDP Act's definitions of data fiduciary and data principal and summarise them in three sentences.

#Further reading

• ISO/IEC 27001:2022 (ISO)

• AICPA: SOC 2 overview

• PCI Security Standards Council: document library

• MeitY: Digital Personal Data Protection Act, 2023

• CERT-In directions of 28 April 2022