Security Compliance Frameworks

Security compliance frameworks provide structured sets of controls, processes, and policies that organisations implement to manage security risk, protect sensitive data, and demonstrate trustworthiness to customers and regulators. This note covers the most common frameworks side-by-side: NIST CSF, SOC 2, ISO 27001, PCI DSS, and HIPAA.

---

Framework Overview

Framework	Who it’s for	Requirement type	Certification / Attestation
NIST CSF	Any organisation; US government context	Voluntary (federal agencies: mandatory)	Self-assessment or third-party
SOC 2	SaaS / cloud service providers	Voluntary (customer requirement)	CPA audit → Type I or Type II report
ISO 27001	Any organisation; global applicability	Voluntary (some contracts require it)	Third-party certification body
PCI DSS	Any org handling card data	Mandatory (card brands require it)	QSA audit or self-assessment
HIPAA	US healthcare organisations + business associates	Mandatory (US federal law)	No certification; regulatory audit

---

NIST Cybersecurity Framework (CSF)

The NIST CSF organises security into 6 core functions (CSF 2.0, 2024):

GOVERN     → Establish security governance, policies, risk strategy
  └─ organisational roles, risk tolerance, supply chain risk management

IDENTIFY   → Understand assets, risks, and vulnerabilities
  └─ asset inventory, risk assessment, vulnerability management

PROTECT    → Implement safeguards
  └─ access control, awareness training, data security, configuration

DETECT     → Find cybersecurity events
  └─ continuous monitoring, anomaly detection, log analysis

RESPOND    → Take action on detected events
  └─ incident response planning, communication, analysis

RECOVER    → Restore capabilities after incidents
  └─ recovery planning, communications, improvements

Each function contains Categories and Subcategories (specific controls, e.g., ID.AM-1: “Inventories of hardware managed by the organization are maintained”).

# NIST CSF self-assessment (quick checklist by function)
# IDENTIFY:
#   [ ] Asset inventory exists and is maintained
#   [ ] Data flows documented
#   [ ] Risk assessment performed within the last year

# PROTECT:
#   [ ] MFA enabled for all privileged access
#   [ ] Principle of least privilege enforced
#   [ ] Security awareness training completed by all staff

# DETECT:
#   [ ] Centralised logging (SIEM) implemented
#   [ ] Alerting configured for authentication failures, privilege escalation
#   [ ] Vulnerability scanning running on schedule

# RESPOND:
#   [ ] Incident response plan documented and tested
#   [ ] IR team contacts defined
#   [ ] Breach notification process documented

# RECOVER:
#   [ ] Backup and recovery tested quarterly
#   [ ] Business continuity plan maintained

NIST CSF Tiers

Tier	Name	Description
Tier 1	Partial	Ad-hoc security; reactive; no formal risk management
Tier 2	Risk Informed	Risk management approved but not organisation-wide
Tier 3	Repeatable	Formal organisation-wide security practices; regularly reviewed
Tier 4	Adaptive	Security is adaptive, continuous, and optimised; shares threat intel

---

SOC 2 (System and Organisation Controls)

SOC 2 is an audit framework for service providers. A CPA firm audits your controls and issues a report that you share with customers to prove your security posture.

Trust Service Criteria

Criterion	What it covers
Security (CC)	Common Criteria - protection against unauthorised access (required for all SOC 2)
Availability	System available per SLA commitments
Processing Integrity	Processing is complete, valid, accurate, and timely
Confidentiality	Information designated confidential is protected
Privacy	Personal information collected/retained/disclosed per policy

Most organisations start with Security only. Adding Availability and Confidentiality is common for enterprise SaaS.

Type I vs Type II

	SOC 2 Type I	SOC 2 Type II
What’s audited	Controls are designed appropriately at a point in time	Controls operate effectively over a period (usually 6-12 months)
Effort	Lower (shorter engagement)	Higher (sustained evidence collection)
Customer value	Lower (proves design, not operation)	Higher (proves sustained operation)
Typical use	Early-stage; demonstrate initial commitment	Established product; enterprise customers

SOC 2 Evidence Examples

# Security common criteria map to your existing controls
# CC6.1 (Logical access controls):
#   Evidence: Screenshot of MFA settings in IdP
#             IAM access review records
#             Onboarding/offboarding ticket records

# CC7.2 (Security monitoring):
#   Evidence: SIEM configuration + sample alert
#             Vulnerability scan schedule and results
#             Patch management records

# CC8.1 (Change management):
#   Evidence: Pull request approvals in GitHub
#             Deployment pipeline configuration
#             Change request tickets

# Collect evidence with scripts (example: export GitHub PR reviews)
curl -s -H "Authorization: token $GITHUB_TOKEN" \
  "https://api.github.com/repos/example/myapp/pulls?state=closed&per_page=100" \
  | jq '[.[] | {number: .number, merged: .merged_at, merged_by: .merged_by.login, reviews: .requested_reviewers}]' \
  > pr-review-evidence.json

---

ISO 27001

ISO 27001 is an international standard for Information Security Management Systems (ISMS). Unlike compliance checklists, it requires an ISMS - a systematic approach to managing security across people, process, and technology.

The ISMS Lifecycle (PDCA)

Plan  → Establish the ISMS scope, risk assessment, risk treatment plan
Do    → Implement controls from Annex A; build processes
Check → Monitor, measure, audit (internal audit annually)
Act   → Address nonconformities; continuous improvement

Annex A - Control Categories (ISO 27001:2022)

ISO 27001:2022 has 93 controls across 4 themes:

Theme	Controls	Examples
Organisational (37 controls)	Policies, roles, supply chain, incident management	Threat intelligence, information security policy
People (8 controls)	HR security, awareness, remote working	Background checks, security training
Physical (14 controls)	Physical perimeter, clean desk, equipment	Data centre access, screen locks
Technological (34 controls)	Access control, crypto, endpoint security	MFA, network segmentation, secure coding

ISO 27001 vs SOC 2

Factor	ISO 27001	SOC 2
Scope	Entire ISMS (people, process, tech)	Specific service/product
Global recognition	Worldwide	Primarily US/Canada
Certification output	Certificate (3 years; annual surveillance)	Type I or Type II report
Ongoing requirement	Annual surveillance audit	Re-audit each period
Main audience	Enterprise customers; EU; government	US enterprise SaaS buyers

---

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS v4.0 (current) is mandatory for any organisation that stores, processes, or transmits cardholder data (PANs, CVVs, expiration dates).

The 12 Requirements

Req	Category	Key requirement
1	Network Security	Install and maintain network security controls (firewall)
2	Network Security	Apply secure configurations to all system components
3	Account Data	Protect stored account data (never store CVV post-auth)
4	Account Data	Protect cardholder data with strong cryptography during transmission
5	Vulnerability	Protect all systems and networks from malicious software
6	Vulnerability	Develop and maintain secure systems and software
7	Access Control	Restrict access to system components and cardholder data by need-to-know
8	Access Control	Identify users and authenticate access to system components
9	Access Control	Restrict physical access to cardholder data
10	Monitoring	Log and monitor all access to system components and cardholder data
11	Testing	Test security of systems and networks regularly
12	Policy	Support information security with organisational policies

PCI Data Categories

What you CAN store (if encrypted/hashed):
  PAN (Primary Account Number)    → must be masked when displayed (only show last 4 digits)
  Cardholder name
  Expiration date
  Service code

What you CANNOT store (under ANY circumstances):
  Full track data (magnetic stripe data)
  CVV / CVC / CID (3-4 digit verification value)
  PIN / PIN block

Scope reduction:
  → Use a PCI-compliant payment processor (Stripe, Braintree)
  → Tokenisation: replace PANs with tokens → removes scope from your systems
  → iframe / hosted payment page: card data never touches your servers

# PCI DSS compliance checks (sample)

# Req 2: Default passwords changed
# Check for default SSH keys on EC2 instances
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,KeyName]'

# Req 3: Check for unencrypted storage containing PAN-like data
grep -rE '\b([0-9]{4}[ -]?){3}[0-9]{4}\b' /var/www/ 2>/dev/null

# Req 10: Log retention (90 days accessible, 12 months total in PCI DSS v4)
# Check CloudWatch log retention
aws logs describe-log-groups --query 'logGroups[?retentionInDays<90].[logGroupName,retentionInDays]'

# Req 11: Quarterly internal and annual external vulnerability scans
# Set up automated scanning schedule

Merchant Levels and Validation

Merchant Level	Transaction volume	Validation
Level 1	> 6M transactions/year	Annual on-site audit by QSA
Level 2	1M – 6M/year	Annual SAQ + quarterly ASV scan
Level 3	20K – 1M/year (e-commerce)	Annual SAQ + quarterly ASV scan
Level 4	< 20K online or < 1M total	SAQ + quarterly scan (recommended)

---

HIPAA (Health Insurance Portability and Accountability Act)

HIPAA governs Protected Health Information (PHI) - any individually identifiable health information - for US healthcare organisations and their business associates.

Key HIPAA Rules

Rule	What it requires
Privacy Rule	Defines PHI, limits uses/disclosures, gives patients access rights
Security Rule	Administrative, physical, and technical safeguards for ePHI
Breach Notification Rule	Notify HHS and affected individuals within 60 days of discovering a breach
Omnibus Rule	Extends liability to Business Associates (vendors handling PHI)

Technical Safeguards (Security Rule)

Required:
  Access control              → Unique user ID, emergency access, auto-logoff
  Audit controls              → Log all ePHI access
  Integrity controls          → Verify ePHI hasn't been altered or destroyed
  Authentication              → Verify that users are who they claim to be
  Transmission security       → Encrypt ePHI in transit (TLS)

Addressable (must implement OR document why not + compensating control):
  Encryption at rest          → Encrypt stored ePHI
  Automatic logoff            → Session timeout
  Encryption in transit       → Already required above (encryption is addressable
                                 but effectively required in practice)

# HIPAA technical safeguard checks

# Unique user IDs (no shared accounts)
# Check for shared accounts in AD / LDAP
ldapsearch -x -H ldap://dc.example.com \
  -D "cn=admin,dc=example,dc=com" -W \
  -b "dc=example,dc=com" \
  "(description=*shared*)" sAMAccountName

# Audit log configuration (all access to ePHI systems)
auditctl -l | grep -E "phi|ehr|emr"

# Encryption at rest (disk encryption)
lsblk -f | grep -E "crypto_LUKS|bitlk"
fdesetup status 2>/dev/null   # macOS FileVault

# Encryption in transit (check web services use TLS)
nmap -p 443 --script ssl-cert ehr-system.example.com

Business Associate Agreements (BAAs)

BAA requirement:
  If a vendor touches PHI (cloud storage, SaaS, IT services),
  you MUST have a signed BAA with them before sharing PHI.

  Without a BAA = HIPAA violation even if the vendor is secure.

Cloud providers with HIPAA BAAs available:
  AWS  → aws.amazon.com/compliance/hipaa-eligible-services-reference
  Azure → Microsoft signs BAA for HIPAA-eligible services
  GCP  → HIPAA compliance supported for many services

  → Not all services are HIPAA-eligible even within these providers
  → Google Drive consumer (not Workspace) = NOT covered

---

Compliance vs Security

Caution

Compliance is a floor, not a ceiling. Passing a SOC 2 audit or achieving PCI DSS compliance does not mean you are secure - it means you met the minimum bar at audit time. Real security requires continuous effort, threat modelling, and adapting to the evolving threat landscape.

Examples of compliant-but-insecure scenarios:

• PCI DSS compliant but password policy allows dictionary words
• ISO 27001 certified but employees share credentials
• SOC 2 Type II report recent but unpatched zero-day in production

Use frameworks as a starting structure, then exceed them.

Framework Mapping - Common Controls

Many controls satisfy multiple frameworks simultaneously:

Control	NIST CSF	SOC 2	ISO 27001	PCI DSS	HIPAA
MFA for remote access	PR.AA	CC6.1	8.05	Req 8	Technical safeguards
Centralised logging	DE.CM	CC7.2	8.16	Req 10	Audit controls
Patch management	PR.PS	CC7.1	8.08	Req 6	Technical safeguards
Encryption at rest	PR.DS	CC6.7	8.24	Req 3	Technical safeguards
Incident response plan	RS	CC7.3	5.24	Req 12	Breach notification
Background checks	PR.AT	CC1.1	6.01	Req 12	Administrative
Vendor management	GV.SC	CC9.2	5.19	Req 12	BAA requirement