Governance and Regulation for QA Engineers

Cybersecurity governance turns security from a collection of technical controls into an organisation-wide management discipline. It defines who is responsible, which risks matter, which policies and standards apply, how compliance is demonstrated and how security performance is reviewed over time. For QA engineers, governance and regulation provide the context behind many requirements we test: access control, data minimisation, logging, incident response, authentication, resilience and evidence that controls actually work.

Governance, regulation and compliance

Term	Meaning
Governance	The structures, responsibilities and decision-making processes used to direct security so that it supports organisational objectives.
Regulation	A binding legal or regulatory requirement enforced by an authorised body.
Compliance	The state of meeting applicable legal, regulatory, contractual, policy and standards-based obligations.

These concepts overlap but are not interchangeable. Governance determines how security is directed. Regulation creates external obligations. Compliance demonstrates that relevant obligations are being met.

What information security governance should achieve

Benefits of effective governance

• Stronger security posture.
• Clear accountability.
• Better alignment between security investment and business risk.
• More consistent controls across teams.
• Improved customer and stakeholder confidence.
• Better readiness for audits and regulatory reviews.
• Faster decision-making when incidents occur.

Laws, regulations, standards and frameworks

A governance programme may need to consider several kinds of external requirements.

Example	Type	Focus
GDPR	EU regulation	Personal-data protection and privacy.
HIPAA	US law / regulatory framework	Protected health information in covered US healthcare contexts.
GLBA	US law	Protection of non-public personal information in financial institutions.
PCI DSS	Industry security standard	Protection of payment-card account data.
ISO/IEC 27001	International management-system standard	Information Security Management Systems.
NIST SP 800-53	NIST control catalogue	Security and privacy controls.
SOC 2	Independent attestation/reporting framework	Controls relevant to Trust Services Criteria.

Information security governance documents

Document	Purpose	Typical strength
Policy	States management intent, principles and mandatory high-level rules.	Mandatory internally.
Standard	Defines specific mandatory requirements or specifications.	Mandatory where adopted.
Procedure	Defines the exact steps used to perform a task.	Operational and repeatable.
Guideline	Provides recommended practices and advice.	Usually non-mandatory.
Baseline	Defines the minimum acceptable security configuration or control level.	Minimum threshold.

Example hierarchy

Password Policy │ ├── Password Standard │ ├── Minimum length │ ├── Block weak passwords │ └── MFA requirements │ ├── Password Reset Procedure │ └── Step-by-step recovery flow │ └── User Guideline └── Advice for password managers

How governance documents are developed

1. Define scope and purpose. What problem does the document solve and who does it apply to?
2. Research requirements. Review applicable laws, standards, contracts, threat intelligence and existing internal documents.
3. Draft clear requirements. Make them specific, measurable and actionable.
4. Review and approve. Include security, engineering, legal/compliance, operations and business stakeholders as relevant.
5. Implement and communicate. Train affected users and update technical processes.
6. Monitor compliance. Collect evidence that requirements are actually followed.
7. Review and update. Revisit documents after incidents, regulatory changes, new threats or material business changes.

Password-policy example

A modern password policy should not simply copy historical rules. It should reflect the current identity standard used by the organisation and the actual risk of the system.

• Define minimum password requirements.
• Prevent known-compromised or weak passwords.
• Specify MFA requirements for higher-risk access.
• Protect password storage using suitable password hashing.
• Secure password reset and account recovery.
• Define how shared and default credentials are handled.
• Monitor compliance and authentication failures.

Incident-response procedure example

An incident-response procedure translates policy into operational actions.

Security Incident ↓ Detection / Reporting ↓ Triage and Classification ↓ Containment ↓ Preserve Evidence ↓ Investigation ↓ Eradication / Remediation ↓ Recovery ↓ Required Notifications ↓ Lessons Learned

A good procedure defines

• Incident types and severity levels.
• Roles and escalation contacts.
• Initial containment actions.
• Evidence-preservation requirements.
• Technical investigation steps.
• Legal, regulatory and customer-notification decision paths.
• Recovery criteria.
• Post-incident review and follow-up actions.

Governance, Risk and Compliance (GRC)

GRC integrates governance, enterprise risk management and compliance instead of treating them as isolated activities.

Developing a GRC programme

1. Define scope, objectives and risk appetite.
2. Inventory important assets, systems, data and obligations.
3. Conduct a risk assessment.
4. Develop required policies, standards and procedures.
5. Establish governance bodies, owners and escalation paths.
6. Select and implement controls.
7. Monitor risk, control effectiveness and compliance.
8. Report meaningful metrics to decision-makers.
9. Improve continuously.

Example risk register entry

Field	Example
Asset	Customer portal
Risk	Account takeover due to weak authentication.
Likelihood	Medium
Impact	High
Controls	MFA, rate limiting, breached-password screening, monitoring.
Owner	Identity / Product Security
Residual risk	Medium-Low
Evidence	Automated authentication tests, configuration evidence, monitoring dashboard.

Monitoring GRC performance

A policy has little value if nobody knows whether it is effective. Metrics should measure outcomes, not only activity.

Weak metric	Stronger metric
Number of vulnerabilities found	Percentage of critical vulnerabilities remediated within SLA.
Number of security trainings delivered	Phishing failure rate and trend after training.
Number of controls documented	Percentage of key controls with current evidence and successful testing.
Number of incidents	Mean detection, containment and recovery time by severity.
Number of access reviews	Percentage of excessive privileges removed within target time.

Privacy and personal-data protection

Privacy governance determines how personal data is collected, used, shared, retained and deleted. The specific obligations depend on jurisdiction and organisational role.

GDPR principles relevant to QA

• Personal data needs a lawful basis for processing.
• Collection should be limited to what is necessary for the intended purpose.
• Data should be accurate and kept only as long as necessary.
• Security controls should protect personal data.
• Data subjects have rights that systems may need to support.
• Organisations must be able to demonstrate accountability.

GDPR QA scenarios

Registration: ✓ Only necessary personal fields required ✓ Optional purposes clearly distinguished ✓ Privacy information available Data export: ✓ Correct identity verification ✓ Only requester's data exported ✓ Secure delivery mechanism Deletion: ✓ Authorised request processed ✓ Expected records removed/anonymised ✓ Required retention exceptions handled Logs: ✓ Personal data minimised ✓ Secrets excluded ✓ Access restricted

GDPR administrative fines

The GDPR provides two principal maximum administrative-fine levels depending on the infringed provisions:

• Up to €10 million or 2% of total worldwide annual turnover for certain obligations.
• Up to €20 million or 4% of total worldwide annual turnover for more serious infringements.

The applicable maximum is not an automatic fine. Supervisory authorities consider the facts and seriousness of each case.

PCI DSS

PCI DSS is an industry security standard designed to protect payment account data. As of 2026, PCI SSC's current published standard is PCI DSS v4.0.1.

Important terminology

• CHD: Cardholder Data.
• CDE: Cardholder Data Environment.
• SAD: Sensitive Authentication Data.

QA implications

• Verify cardholder data is not exposed in logs, URLs or client storage.
• Test access restrictions around payment systems.
• Verify TLS is required for sensitive transmission.
• Test session controls for administrative payment access.
• Confirm masking rules are applied where card numbers are displayed.
• Verify payment-related audit events.
• Ensure test environments do not use real cardholder data unless specifically governed and permitted.

Example: log-safety check

Payment submitted: 4111 1111 1111 1111 Application log must NOT contain: 4111111111111111 CVV Authentication secrets Expected diagnostic data: Transaction ID Masked PAN where policy allows Result code Request correlation ID

NIST SP 800-53 Revision 5

NIST SP 800-53 Rev. 5 provides a broad catalogue of security and privacy controls for information systems and organisations. It is designed to be tailorable rather than a one-size-fits-all checklist.

Selected control families

Family	Examples
Access Control (AC)	Account permissions, least privilege, remote access.
Audit and Accountability (AU)	Logging, audit review and protection.
Configuration Management (CM)	Baselines, change control, least functionality.
Identification and Authentication (IA)	User/service identity and authentication.
Incident Response (IR)	Incident handling, reporting, testing and lessons learned.
Media Protection (MP)	Protection, transport, sanitisation and access to media.
Risk Assessment (RA)	Risk assessments, vulnerability monitoring.
System and Communications Protection (SC)	Network boundaries, encryption and secure communications.
System and Information Integrity (SI)	Flaw remediation, malicious-code protection and monitoring.
Program Management (PM)	Organisation-wide information-security and privacy programme controls.

Implementing a control framework

1. Inventory systems, data, dependencies and business processes.
2. Identify threats, obligations and risk.
3. Select and tailor relevant controls.
4. Assign control ownership.
5. Implement technical and organisational measures.
6. Define evidence for each key control.
7. Assess effectiveness periodically.
8. Remediate gaps and reassess.

NIST SP 800-63B-4: authentication

The TryHackMe material references NIST SP 800-63B. The current publication is NIST SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management, published in 2025. It superseded the earlier SP 800-63B guidance.

Why this matters for QA

Identity requirements increasingly involve more than password complexity. Test plans may need to cover:

• Authenticator enrolment.
• Multiple authenticator types.
• Authenticator Assurance Levels (AALs).
• Phishing-resistant authentication for higher-risk contexts.
• Recovery and replacement of authenticators.
• Session management.
• Rate limiting and attack resistance.
• Secure handling of authentication secrets.

Authentication test matrix

Area	Example tests
Enrolment	Unauthorised users cannot register an authenticator for another account.
Login	Correct factors are required for the applicable assurance level.
Recovery	Recovery cannot bypass stronger authentication requirements without appropriate proof.
Rate limiting	Repeated failed attempts trigger configured protections.
Session	Expired or revoked sessions cannot access protected resources.
Secrets	Passwords, OTP seeds and tokens are absent from logs.

ISO/IEC 27001:2022

ISO/IEC 27001:2022 defines requirements for establishing, implementing, maintaining and continually improving an Information Security Management System (ISMS).

Core ISMS concepts

Concept	Purpose
Scope	Defines which organisational boundaries, systems and processes are part of the ISMS.
Information-security policy	Sets management direction and principles.
Risk assessment	Identifies and evaluates information-security risk.
Risk treatment	Selects how risks will be reduced, avoided, shared or accepted.
Statement of Applicability (SoA)	Documents relevant Annex A controls and why they are included or excluded.
Internal audit	Checks whether the ISMS conforms and operates effectively.
Management review	Ensures leadership periodically reviews ISMS performance and changes.
Continual improvement	Corrects issues and improves ISMS suitability and effectiveness over time.

Risk treatment example

Risk: Shared administrator accounts make actions untraceable. Treatment: Remove shared accounts. Issue named privileged identities. Require MFA. Log privileged activity. Review access quarterly. QA / evidence: Attempt shared-login path → rejected. Named admin login → accepted with MFA. Audit event contains named identity.

SOC 2

SOC 2 is an AICPA attestation framework for reporting on controls at service organisations relevant to the Trust Services Criteria.

Five Trust Services categories

Category	What it considers
Security	Protection against unauthorised access and related risks.
Availability	Whether systems are available for operation and use as committed or agreed.
Processing Integrity	Whether system processing is complete, valid, accurate, timely and authorised as relevant.
Confidentiality	Protection of information designated as confidential.
Privacy	Collection, use, retention, disclosure and disposal of personal information according to applicable criteria and commitments.

The currently published AICPA Trust Services Criteria are the 2017 criteria with revised Points of Focus from 2022.

What an audit may examine

• Access management.
• Change management.
• Security monitoring.
• Incident management.
• Availability and recovery controls.
• Encryption.
• Vendor management.
• Employee security processes.
• Privacy controls where in scope.

SOC 2 Type I vs Type II

Report	Focus
Type I	Design of controls at a specified point in time.
Type II	Design and operating effectiveness of controls over a defined period.

This distinction is important for QA and compliance evidence: a control can be well-designed on paper but fail to operate consistently in practice.

Control design vs control effectiveness

Control design

Requirement: All production administrator access requires MFA. Control design: Identity provider policy requires MFA for prod-admin group.

Operating effectiveness

Evidence: ✓ All current administrators belong to prod-admin group ✓ MFA policy active throughout review period ✓ Sampled admin logins show MFA challenge ✓ No exception accounts bypass policy ✓ Access reviews completed on schedule

How QA supports governance and compliance

Turn policy into testable requirements

Policies are only useful to engineering when requirements can be translated into observable behaviour.

Policy statement

"Only authorised administrators may modify user roles."

Testable requirements

Normal user: PATCH /users/123/role → 403 Support user: PATCH /users/123/role → 403 Admin user: PATCH /users/123/role → allowed All attempts: Audit event recorded Actor identity included Old and new values captured safely

Policy statement

"Sensitive information must not be exposed in logs."

Testable requirements

Run: Login Password reset Payment API-key creation Error scenarios Verify logs do not contain: Passwords Raw tokens Private keys Full card numbers Sensitive PII beyond documented need

Compliance evidence

Good evidence is repeatable, attributable and tied to the actual control.

Weak evidence	Stronger evidence
“MFA is enabled.”	Configuration export + test proving privileged login requires MFA.
Screenshot of a setting.	Versioned configuration plus execution result and timestamp.
“Backups exist.”	Backup job evidence plus successful restore test.
“Access is reviewed.”	Dated review, approver, identified exceptions and remediation evidence.
“TLS is used.”	Automated check of required endpoints and accepted protocol/certificate configuration.

Useful metadata for automated evidence

• Control / requirement identifier.
• Test-case identifier.
• Execution time.
• Application build or commit.
• Environment.
• Result.
• Relevant logs or screenshots.
• Tool/version used.

Continuous compliance in CI/CD

Pull Request │ ├─ Secret scanning ├─ Dependency scanning ├─ Static analysis ├─ Policy-as-code checks └─ Security unit/API tests │ ▼ Build │ ├─ Artefact provenance ├─ Container/image scanning └─ Configuration validation │ ▼ QA Environment │ ├─ Authentication regression ├─ Authorisation matrix ├─ Privacy/data tests ├─ Logging checks └─ Recovery/smoke tests │ ▼ Production │ ├─ Monitoring ├─ Control evidence ├─ Access reviews └─ Incident metrics

Not every compliance requirement can or should be automated, but recurring technical controls are strong candidates.

Governance pitfalls

Pitfall	Better approach
Writing policies that engineering cannot implement.	Involve technical owners before approval.
Copying another company's policy.	Base requirements on your own assets, risk and obligations.
Equating compliance with security.	Treat compliance as a minimum/control framework, not proof of zero risk.
Collecting screenshots once per year.	Automate recurring evidence where practical.
Using outdated versions of standards.	Track revisions and transition requirements.
Measuring activity instead of outcomes.	Use KPIs/KRIs tied to control effectiveness and risk.
Assigning controls without owners.	Give every key control accountable ownership.
Ignoring exceptions.	Document, approve, time-limit and monitor exceptions.
Keeping audit findings separate from product work.	Track remediation in the normal engineering workflow.

A practical QA governance workflow

1. Identify the governing requirement. Policy, law, contract, control or standard.
2. Understand scope. Which system, data, environment and roles are affected?
3. Translate into behaviour. What must be allowed, denied, logged, retained or protected?
4. Choose evidence. Automated test, configuration check, manual review or operational metric.
5. Automate stable controls. Put high-value repeatable checks into CI/CD.
6. Capture traceability. Link result to requirement/control ID.
7. Investigate failures as control failures. Do not dismiss them as “just test issues”.
8. Review after change. Regulatory, architecture and product changes can invalidate previous evidence.

Governance & Regulation QA checklist

• Applicable laws, standards and contractual obligations are identified.
• The organisation understands why each framework applies.
• Security policies have owners and review dates.
• Policies are supported by actionable standards and procedures.
• Key security controls have named owners.
• Risk assessments are updated after material system changes.
• Control effectiveness is measured, not merely documented.
• Compliance exceptions are approved, time-limited and tracked.
• Personal data collected by the application is understood.
• Data minimisation is tested.
• Access to personal data is role-appropriate.
• Privacy export/deletion workflows are tested where applicable.
• Payment-card information is protected according to PCI scope.
• Authentication requirements reference current identity guidance.
• Privileged access is tested separately from ordinary access.
• Security and privacy events produce appropriate audit evidence.
• Sensitive data does not appear in logs.
• Backup controls include restore testing.
• Incident procedures include clear roles and escalation.
• Security tests are traceable to governance requirements.
• Automated evidence includes environment, build and timestamp.
• Standards/framework versions are reviewed periodically.
• Audit findings become tracked remediation work.
• Security metrics are reported in business-risk terms.
• GRC is treated as a continuous programme rather than an annual audit exercise.

Governance cheat sheet

Concept	Remember
Governance	Direction, accountability and oversight.
Risk Management	Identify, assess, treat and monitor risk.
Compliance	Meet and demonstrate applicable obligations.
Policy	High-level mandatory intent.
Standard	Specific mandatory requirement.
Procedure	Step-by-step operational instructions.
Guideline	Recommended practice.
Baseline	Minimum acceptable configuration.
GDPR	EU personal-data regulation.
PCI DSS	Payment account data security standard; current v4.0.1.
NIST SP 800-53	Security/privacy control catalogue; current Rev. 5.
NIST SP 800-63B-4	Current NIST authentication and authenticator guidance.
ISO/IEC 27001:2022	Requirements for an ISMS.
SOC 2	Attestation on service-organisation controls relevant to Trust Services Criteria.

Key takeaways

• Governance makes security accountable and aligned with business objectives.
• Regulations, standards and assurance frameworks serve different purposes.
• GRC integrates governance, risk and compliance into one management approach.
• Policies become useful to QA when converted into observable, testable requirements.
• GDPR testing should cover the full personal-data lifecycle, not only consent UI.
• PCI DSS v4.0.1 is the current PCI DSS version published by PCI SSC.
• NIST SP 800-53 Rev. 5 remains a major security/privacy control catalogue.
• NIST SP 800-63B-4 supersedes the older 800-63B authentication guidance.
• ISO/IEC 27001:2022 focuses on a continually improving risk-based ISMS.
• SOC 2 provides independent assurance over controls relevant to security, availability, processing integrity, confidentiality and privacy.
• Compliance evidence is strongest when repeatable, traceable and tied directly to control effectiveness.
• QA automation can turn many annual compliance checks into continuous controls.

Useful links

• European Commission — Data Protection ↗ — GDPR information and guidance.
• European Data Protection Board ↗ — GDPR guidance and enforcement material.
• PCI SSC Document Library ↗ — current PCI DSS standard and supporting documents.
• NIST SP 800-53 Rev. 5 ↗ — Security and Privacy Controls for Information Systems and Organizations.
• NIST SP 800-63B-4 ↗ — current authentication and authenticator-management guidance.
• ISO/IEC 27001:2022 ↗ — Information Security Management Systems requirements.
• AICPA SOC 2 ↗ — Trust Services Criteria and SOC 2 resources.