compliance-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Compliance Review

合规审查

Evaluate your application against industry-specific regulatory requirements. This review translates dense compliance frameworks into concrete, testable technical checks — and validates them through browser-based testing. Non-compliance can result in severe fines, legal action, and loss of business.

针对行业特定的监管要求评估您的应用程序。本次审查将复杂的合规框架转化为具体、可测试的技术检查项，并通过基于浏览器的测试进行验证。不合规可能导致巨额罚款、法律诉讼以及业务损失。

When to use

使用场景

Use

/compliance-review

when:

Building applications for regulated industries (healthcare, finance, government)
Preparing for a compliance audit (SOC 2, HIPAA, PCI-DSS)
Adding payment processing or health data features
Expanding to GDPR-regulated markets
After infrastructure or architecture changes that affect data handling

在以下场景使用

/compliance-review

：

为受监管行业（医疗保健、金融、政府）构建应用程序
准备合规审计（SOC 2、HIPAA、PCI-DSS）
添加支付处理或健康数据功能
拓展至受GDPR监管的市场
基础设施或架构变更影响数据处理之后

Standards Referenced

参考标准

HIPAA — Health Insurance Portability and Accountability Act (Technical Safeguards §164.312)
SOC 2 — Service Organization Control (Trust Service Criteria)
PCI-DSS v4.0 — Payment Card Industry Data Security Standard
GDPR — General Data Protection Regulation (Technical Measures)

HIPAA — 健康保险流通与责任法案（技术保障措施 §164.312）
SOC 2 — 服务组织控制（信任服务准则）
PCI-DSS v4.0 — 支付卡行业数据安全标准
GDPR — 通用数据保护条例（技术措施）

Phase Overview

阶段概述

Phase 1: EDUCATE   → Compliance context and applicable frameworks
Phase 2: SCOPE     → Determine which frameworks apply, identify regulated data
Phase 3: ANALYZE   → Browser-based checks against framework requirements
Phase 4: REPORT    → Findings mapped to specific regulatory sections
Phase 5: REMEDIATE → Fix guidance + YAML regression tests for continuous compliance

Phase 1: EDUCATE   → 合规背景与适用框架
Phase 2: SCOPE     → 确定适用框架，识别受监管数据
Phase 3: ANALYZE   → 基于框架要求的浏览器端检查
Phase 4: REPORT    → 映射到具体监管条款的检查结果
Phase 5: REMEDIATE → 修复指南 + 用于持续合规的YAML回归测试

Phase 1: Educate

第一阶段：认知

Why this matters: HIPAA violations: up to $1.9M per violation category per year. PCI-DSS non-compliance: $5,000-$100,000/month in fines plus liability for breaches. SOC 2 failures: loss of enterprise customers who require it. GDPR: up to 4% of global annual revenue. These aren't theoretical — enforcement is active and increasing.

Compliance frameworks are large documents. This review extracts the technical requirements testable in a web application — not the organizational/procedural requirements (policies, training, vendor management) that require human process review.

重要性说明： HIPAA违规：每年每类违规最高罚款190万美元。PCI-DSS不合规：每月罚款5000-10万美元，外加数据泄露责任。SOC 2不达标：失去要求该认证的企业客户。GDPR：最高罚款全球年营收的4%。这些并非理论风险——监管执法正在加强且力度不断增大。

合规框架篇幅庞大。本次审查仅提取Web应用中可测试的技术要求，不包含需要人工流程审查的组织/程序要求（如政策、培训、供应商管理）。

Phase 2: Scope

第二阶段：范围界定

Determine applicable frameworks

确定适用框架

Phase 3: Analyze

第三阶段：分析

Run only the sections applicable based on Phase 2 scoping. Open a browser session with

new_session

using

record_evidence: true

仅执行第二阶段范围界定中适用的部分。使用

new_session

打开浏览器会话，设置

record_evidence: true

。

HIPAA Technical Safeguards (HIP)

HIPAA技术保障措施（HIP）

Applicable when: application handles Protected Health Information (PHI).

Check ID	Check	HIPAA Section	Method
HIP-01	PHI not displayed without authentication	§164.312(d)	Access PHI pages without auth, verify 401/redirect
HIP-02	Session auto-timeout after inactivity	§164.312(a)(2)(iii)	Wait for idle period, verify session expiration
HIP-03	PHI not in URL parameters	§164.312(e)(1)	Navigate PHI pages, check URLs
HIP-04	PHI not in browser console/logs	§164.312(b)	Check `get_browser_console_logs` for PHI patterns
HIP-05	PHI not cached in browser storage	§164.312(a)(2)(iv)	Check localStorage, sessionStorage for PHI
HIP-06	PHI transmitted over HTTPS only	§164.312(e)(1)	Verify all PHI API calls use HTTPS
HIP-07	Audit trail for PHI access	§164.312(b)	Access PHI, verify audit log entry exists
HIP-08	Role-based access to PHI	§164.312(a)(1)	Test PHI access with different user roles
HIP-09	PHI display has minimum necessary principle	§164.502(b)	Check if UI shows only needed PHI fields
HIP-10	Emergency access procedure exists	§164.312(a)(2)(ii)	Check for break-glass or emergency access UI
HIP-11	No PHI in error messages	§164.312(b)	Trigger errors on PHI pages, check messages
HIP-12	Logout fully terminates PHI access	§164.312(a)(2)(iii)	Logout, back button, check no PHI visible

Browser validation: Navigate to pages with PHI. Test access controls. Check for PHI in URLs, storage, console. Test session timeout by waiting. Test logout completeness.

适用场景：应用程序处理受保护健康信息（PHI）。

检查ID	检查项	HIPAA条款	方法
HIP-01	未认证无法查看PHI	§164.312(d)	未认证访问PHI页面，验证返回401/重定向
HIP-02	闲置后会话自动超时	§164.312(a)(2)(iii)	等待闲置时长，验证会话过期
HIP-03	PHI不包含在URL参数中	§164.312(e)(1)	浏览PHI页面，检查URL
HIP-04	PHI不出现于浏览器控制台/日志	§164.312(b)	检查 `get_browser_console_logs` 中的PHI模式
HIP-05	PHI不缓存于浏览器存储	§164.312(a)(2)(iv)	检查localStorage、sessionStorage中的PHI
HIP-06	PHI仅通过HTTPS传输	§164.312(e)(1)	验证所有PHI相关API调用使用HTTPS
HIP-07	PHI访问审计跟踪	§164.312(b)	访问PHI，验证审计日志条目存在
HIP-08	PHI的基于角色访问控制	§164.312(a)(1)	测试不同用户角色的PHI访问权限
HIP-09	PHI展示遵循最小必要原则	§164.502(b)	检查UI是否仅显示必要的PHI字段
HIP-10	存在紧急访问流程	§164.312(a)(2)(ii)	检查应急访问或紧急权限UI
HIP-11	错误信息中无PHI	§164.312(b)	在PHI页面触发错误，检查提示信息
HIP-12	登出完全终止PHI访问权限	§164.312(a)(2)(iii)	登出后点击返回按钮，检查无PHI可见

浏览器验证： 导航至含PHI的页面，测试访问控制，检查URL、存储、控制台中的PHI，等待测试会话超时，验证登出完整性。

SOC 2 Trust Service Criteria (SOC)

SOC 2信任服务准则（SOC）

Applicable when: enterprise SaaS handling customer data.

Check ID	Check	SOC 2 Criteria	Method
SOC-01	Authentication required for all data access	CC6.1	Access data pages without auth
SOC-02	Strong password requirements enforced	CC6.1	Test signup/password change with weak passwords
SOC-03	MFA available for user accounts	CC6.1	Check account security settings for MFA option
SOC-04	Session management is secure	CC6.1	Check cookie flags, timeout, logout behavior
SOC-05	Data is encrypted in transit	CC6.7	Verify HTTPS everywhere, check for mixed content
SOC-06	Access is logged (audit trail)	CC7.2	Perform actions, verify audit log entries
SOC-07	Failed login attempts are monitored	CC7.2	Multiple failed logins, check for alerting/lockout
SOC-08	User permissions are role-based	CC6.3	Test different roles, verify appropriate access
SOC-09	Data deletion is available	CC6.5	Test account/data deletion functionality
SOC-10	System status page or health endpoint	CC7.1	Check for status page or /health endpoint
SOC-11	Error handling doesn't leak internal details	CC7.4	Trigger errors, check for stack traces
SOC-12	Change management evident (versioning)	CC8.1	Check for version info, changelog

Browser validation: Test authentication boundaries, password policies, MFA flows, role-based access, audit logging visibility.

适用场景：处理客户数据的企业级SaaS。

检查ID	检查项	SOC 2准则	方法
SOC-01	所有数据访问需认证	CC6.1	未认证访问数据页面
SOC-02	强制执行强密码要求	CC6.1	使用弱密码测试注册/密码修改
SOC-03	用户账户支持MFA	CC6.1	检查账户安全设置中的MFA选项
SOC-04	会话管理安全	CC6.1	检查Cookie标记、超时设置、登出行为
SOC-05	数据传输加密	CC6.7	验证全站HTTPS，检查混合内容
SOC-06	访问行为记录（审计跟踪）	CC7.2	执行操作，验证审计日志条目
SOC-07	监控登录失败尝试	CC7.2	多次登录失败，检查告警/锁定机制
SOC-08	用户权限基于角色分配	CC6.3	测试不同角色，验证对应访问权限
SOC-09	支持数据删除	CC6.5	测试账户/数据删除功能
SOC-10	系统状态页或健康检查端点	CC7.1	检查状态页或/health端点
SOC-11	错误处理不泄露内部细节	CC7.4	触发错误，检查是否存在堆栈跟踪
SOC-12	可见的变更管理（版本控制）	CC8.1	检查版本信息、更新日志

浏览器验证： 测试认证边界、密码策略、MFA流程、基于角色的访问控制、审计日志可见性。

PCI-DSS v4.0 (PCI)

PCI-DSS v4.0（PCI）

Applicable when: application processes, stores, or transmits cardholder data.

Check ID	Check	PCI-DSS Req	Method
PCI-01	Credit card numbers never fully displayed	3.4	View saved cards, verify masking (show last 4 only)
PCI-02	CVV never stored or displayed after authorization	3.3.2	Check storage, API responses for CVV
PCI-03	Payment form uses HTTPS	4.1	Verify payment page URL and all resources
PCI-04	Payment form is on compliant iframe/redirect	SAQ A	Check if using Stripe Elements, PayPal, or similar
PCI-05	No cardholder data in URL parameters	4.2	Check URLs during payment flow
PCI-06	No cardholder data in client storage	3.2	Check localStorage, sessionStorage, cookies
PCI-07	No cardholder data in console logs	3.2	Check `get_browser_console_logs` during payment
PCI-08	Payment form prevents autocomplete on card fields	Best practice	Check `autocomplete="off"` on sensitive fields
PCI-09	Strong authentication for payment admin	8.3	Verify admin/payment management requires strong auth
PCI-10	Access to cardholder data is role-restricted	7.1	Test access to payment data with non-admin users
PCI-11	Payment error messages don't reveal card details	3.2	Trigger payment errors, check messages
PCI-12	CSP prevents unauthorized scripts on payment pages	6.4.3	Check CSP header on payment pages specifically

Browser validation: Walk through the payment flow. Check card display masking. Inspect storage and console for cardholder data. Verify payment form is iframe/hosted (SAQ A compliance).

适用场景：处理、存储或传输持卡人数据的应用程序。

检查ID	检查项	PCI-DSS要求	方法
PCI-01	信用卡号从不完整显示	3.4	查看已保存卡片，验证掩码（仅显示后4位）
PCI-02	CVV授权后从不存储或显示	3.3.2	检查存储、API响应中的CVV
PCI-03	支付表单使用HTTPS	4.1	验证支付页面URL及所有资源
PCI-04	支付表单使用合规iframe/重定向	SAQ A	检查是否使用Stripe Elements、PayPal等工具
PCI-05	持卡人数据不包含在URL参数中	4.2	检查支付流程中的URL
PCI-06	持卡人数据不存储于客户端	3.2	检查localStorage、sessionStorage、Cookie
PCI-07	持卡人数据不出现于控制台日志	3.2	支付过程中检查 `get_browser_console_logs`
PCI-08	支付表单禁用卡片字段自动填充	最佳实践	检查敏感字段的 `autocomplete="off"` 设置
PCI-09	支付管理员需强认证	8.3	验证管理员/支付管理需强认证
PCI-10	持卡人数据访问受角色限制	7.1	测试非管理员用户的支付数据访问权限
PCI-11	支付错误信息不泄露卡片细节	3.2	触发支付错误，检查提示信息
PCI-12	支付页面CSP阻止未授权脚本	6.4.3	检查支付页面的CSP头

浏览器验证： 完成支付流程测试，检查卡片显示掩码，检查存储和控制台中的持卡人数据，验证支付表单为iframe/托管式（符合SAQ A合规）。

GDPR Technical Requirements (GDPR)

GDPR技术要求（GDPR）

Applicable when: application handles EU personal data. (Note: privacy-specific checks are in

/privacy-review

— this section covers GDPR's technical/compliance obligations.)

Check ID	Check	GDPR Article	Method
GDPR-01	Consent collected before data processing	Art. 6, 7	Load page, check if processing occurs before consent
GDPR-02	Privacy policy is accessible and current	Art. 13, 14	Find and verify privacy policy page
GDPR-03	Data subject access request mechanism exists	Art. 15	Find data export/download feature
GDPR-04	Right to erasure is implemented	Art. 17	Find and test account deletion
GDPR-05	Data portability (export in standard format)	Art. 20	Test data export, verify format (JSON/CSV)
GDPR-06	Consent withdrawal is as easy as giving consent	Art. 7(3)	Compare consent-giving vs withdrawal UX
GDPR-07	Age verification for minors (if applicable)	Art. 8	Check for age gate or parental consent
GDPR-08	Data processing records accessible	Art. 30	Check for processing activity documentation
GDPR-09	Data breach notification mechanism	Art. 33, 34	Check for incident response documentation
GDPR-10	Cross-border transfer safeguards	Art. 44-49	Check where third-party services are hosted

Browser validation: Test consent flows, data export, account deletion, privacy policy accessibility. Check third-party script origins for cross-border transfer concerns.

适用场景：处理欧盟个人数据的应用程序。（注：隐私专项检查在

/privacy-review

中——本节涵盖GDPR的技术/合规义务。）

检查ID	检查项	GDPR条款	方法
GDPR-01	数据处理前收集用户同意	Art. 6, 7	加载页面，检查是否在获得同意前进行数据处理
GDPR-02	隐私政策可访问且内容最新	Art. 13, 14	查找并验证隐私政策页面
GDPR-03	存在数据主体访问请求机制	Art. 15	查找数据导出/下载功能
GDPR-04	实现删除权（被遗忘权）	Art. 17	查找并测试账户删除功能
GDPR-05	数据可移植性（标准格式导出）	Art. 20	测试数据导出，验证格式（JSON/CSV）
GDPR-06	撤回同意与给予同意同样便捷	Art. 7(3)	对比同意授予与撤回的用户体验
GDPR-07	未成年人年龄验证（如适用）	Art. 8	检查年龄验证 gate 或家长同意机制
GDPR-08	可访问数据处理记录	Art. 30	检查处理活动文档
GDPR-09	数据泄露通知机制	Art. 33, 34	检查事件响应文档
GDPR-10	跨境传输保障措施	Art. 44-49	检查第三方服务的托管位置

浏览器验证： 测试同意流程、数据导出、账户删除、隐私政策可访问性，检查第三方脚本来源的跨境传输风险。

Phase 4: Report

第四阶段：报告

Generate a structured report saved to

shiplight/reports/compliance-review-{date}.md

markdown

undefined

生成结构化报告并保存至

shiplight/reports/compliance-review-{date}.md

markdown

undefined

Compliance Review Report

合规审查报告

Date: {date} URL: {url} Frameworks evaluated: {HIPAA, SOC 2, PCI-DSS, GDPR} Regulated data types: {PHI, cardholder data, EU personal data}

日期: {date} URL: {url} 评估框架: {HIPAA, SOC 2, PCI-DSS, GDPR} 受监管数据类型: {PHI,持卡人数据,欧盟个人数据}

Overall Compliance Score: {X}/10 | Confidence: {X}%

整体合规评分: {X}/10 | 置信度: {X}%

Framework Scores

框架评分

Framework	Score	Pass	Fail	N/A	Critical Gaps
HIPAA	6/10	8	3	1	Session timeout, PHI in URL
SOC 2	7/10	9	2	1	No MFA, weak audit trail
PCI-DSS	8/10	10	1	1	Card data in console
GDPR	5/10	5	4	1	Consent, data export, erasure

框架	评分	通过	失败	不适用	关键差距
HIPAA	6/10	8	3	1	会话超时、URL含PHI
SOC 2	7/10	9	2	1	无MFA、审计跟踪薄弱
PCI-DSS	8/10	10	1	1	控制台含卡片数据
GDPR	5/10	5	4	1	同意机制、数据导出、删除权

Compliance Status by Check

检查项合规状态

(Full table of all checks with PASS/FAIL/N-A status, evidence, and confidence)

（所有检查项的完整表格，包含通过/失败/不适用状态、证据及置信度）

Critical Non-Compliance Items

严重不合规项

(Findings that could result in regulatory action, ordered by risk)

（可能引发监管行动的检查结果，按风险排序）

Audit Preparation Checklist

审计准备清单

Fix all CRITICAL findings
Fix all HIGH findings
Document accepted risks for MEDIUM findings
Run YAML regression tests before audit date
Prepare evidence documentation from this report

undefined

修复所有严重问题
修复所有高风险问题
记录中等风险问题的可接受风险
审计前运行YAML回归测试
准备本报告中的证据文档

undefined

Confidence Scoring

置信度评分

90-100%: Browser-validated, compliance violation confirmed (e.g., PHI visible without auth, card number in console)
70-89%: Strong evidence from inspection (e.g., missing header, no timeout behavior)
50-69%: Architectural concern based on code patterns (e.g., audit logging might be incomplete)
Below 50%: Don't report — compliance findings must be substantiated

90-100%: 浏览器验证确认合规违规（如未认证可查看PHI、控制台含卡号）
70-89%: 检查发现确凿证据（如缺失头文件、无超时行为）
50-69%: 基于代码模式的架构风险（如审计日志可能不完整）
低于50%: 不予报告——合规检查结果必须有充分依据

Phase 5: Remediate

第五阶段：整改

1. Fix guidance (example)

1. 修复指南（示例）

markdown

undefined

markdown

undefined

HIP-02: No session auto-timeout

HIP-02: 无会话自动超时

Regulation: HIPAA §164.312(a)(2)(iii) — Automatic logoff Risk: Unattended sessions with PHI visible Current: Sessions persist indefinitely Fix: Implement idle timeout (HIPAA recommends ≤15 minutes for PHI access)

Add client-side idle detection (mouse, keyboard events)
Server-side session expiry as backup
Show warning dialog at 12 minutes
Auto-logout and clear screen at 15 minutes

undefined

监管要求: HIPAA §164.312(a)(2)(iii) — 自动登出 风险: 无人值守会话暴露PHI 现状: 会话永久保持 修复方案: 实现闲置超时（HIPAA建议PHI访问超时≤15分钟）

添加客户端闲置检测（鼠标、键盘事件）
服务器端会话过期作为备份
12分钟时显示警告弹窗
15分钟时自动登出并清空屏幕

undefined

2. YAML regression test

2. YAML回归测试

yaml

- name: hip-02-session-auto-timeout
  description: Verify session auto-timeout for HIPAA compliance
  severity: critical
  standard: HIPAA-164.312(a)(2)(iii)
  steps:
    - URL: /login
    - intent: Log in with test credentials
      action: fill
      locator: "getByLabel('Email')"
      value: "test@example.com"
    - intent: Enter password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Submit login form
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: Dashboard with PHI is visible
      timeout_seconds: 15
    - VERIFY: Session timeout warning appears after inactivity period
      timeout_seconds: 900
    - VERIFY: User is automatically logged out after timeout expires
      timeout_seconds: 300

Save all YAML tests to

shiplight/tests/compliance-review.test.yaml

yaml

- name: hip-02-session-auto-timeout
  description: Verify session auto-timeout for HIPAA compliance
  severity: critical
  standard: HIPAA-164.312(a)(2)(iii)
  steps:
    - URL: /login
    - intent: Log in with test credentials
      action: fill
      locator: "getByLabel('Email')"
      value: "test@example.com"
    - intent: Enter password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Submit login form
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: Dashboard with PHI is visible
      timeout_seconds: 15
    - VERIFY: Session timeout warning appears after inactivity period
      timeout_seconds: 900
    - VERIFY: User is automatically logged out after timeout expires
      timeout_seconds: 300

将所有YAML测试保存至

shiplight/tests/compliance-review.test.yaml

。

Depth Levels

深度级别

--quick
: Critical checks only — authentication boundaries + data exposure. ~3 minutes.
default: Full applicable framework. ~10-15 minutes.
--thorough
: All checks + multi-role testing + edge cases + documentation review. ~25-40 minutes.

--quick
: 仅关键检查——认证边界 + 数据泄露检测，约3分钟
默认: 完整适用框架检查，约10-15分钟
--thorough
: 所有检查 + 多角色测试 + 边缘案例 + 文档审查，约25-40分钟

Tips

提示

Run the compliance review specific to your framework: "run HIPAA checks only"
Compliance requires evidence — use
```
record_evidence: true
```
and
```
generate_html_report
```
for audit documentation
YAML regression tests from this review serve as continuous compliance monitoring
This review covers technical requirements only — organizational requirements (policies, training) need human review
For privacy-specific concerns, complement with
```
/privacy-review
```
For security-specific concerns, complement with
```
/security-review
```
Close session with
```
close_session
```
and use
```
generate_html_report
```
for evidence

针对特定框架运行合规审查："仅运行HIPAA检查"
合规需要证据——使用
```
record_evidence: true
```
和
```
generate_html_report
```
生成审计文档
本次审查生成的YAML回归测试可用于持续合规监控
本次审查仅覆盖技术要求——组织要求（政策、培训）需人工审查
隐私专项问题请配合
```
/privacy-review
```
使用
安全专项问题请配合
```
/security-review
```
使用
使用
```
close_session
```
关闭会话，并用
```
generate_html_report
```
生成证据