Compliance Specialist

Compliance Specialist

When to Use

• Select and scope frameworks (SOC 2 Type I/II, ISO 27001, HIPAA, PCI, GDPR-style privacy program)
• Build control mapping and gap assessments with remediation plans and owners
• Draft policy and procedure outlines aligned to in-scope controls (not legal advice)
• Prepare audit and assessor coordination — calendars, walkthrough agendas, request lists
• Support vendor security questionnaires (SIG, CAIQ, custom) with consistent answers and evidence pointers
• Design continuous compliance — control inventory, review cadence, exception register, metrics
• Align GRC program roles, RACI, and executive reporting before engineering evidence work

When NOT to Use

• Automate evidence from IdP, CI/CD, CSPM, or build CCM pipelines → compliance-engineer
• Cloud API evidence, shared responsibility, FedRAMP/PCI in AWS/GCP/Azure → cloud-compliance-specialist
• Implement IAM, encryption, SCPs, or CSPM rules → information-security-engineer, cloud-security-engineer
• Interpret law, negotiate DPAs, or redline contracts → commercial-counsel
• Enterprise security strategy without audit/program lens → cybersecurity
• Inherent/residual risk scoring and risk register → security-risk-analyst
• Execute penetration tests → penetration-tester

Related skills

Core Workflows

1. Program charter and framework selection

1. Document business drivers (customer contracts, sector, geography) 2. Inventory systems, data classes, and subprocessors 3. Select frameworks and trust criteria / Annex A scope 4. Define observation period, audit windows, and exclusions with risk acceptance 5. Assign program owner, control owners, and executive sponsor

See `references/compliance_specialist_scope.md`.

2. Control mapping and gap assessment

Map each in-scope requirement to policy, procedure, technical control, and evidence type. Classify gaps: missing, partial, implemented. Prioritize by audit date and customer impact.

See `references/framework_scoping_and_mapping.md` and `references/gap_assessment_and_remediation_planning.md`.

3. Policies, procedures, and evidence design

Draft outlines stakeholders can approve; define evidence requirements (what, who, cadence)—hand implementation collectors to compliance-engineer.

See `references/policies_procedures_evidence.md`.

4. Audit and assessor coordination

Prepare request lists, walkthrough scripts, point-of-contact roster, and exception register. Coordinate with engineering for live demos only when narratives need validation.

See `references/audit_and_assessor_coordination.md`.

5. Vendor and continuous compliance

Standardize questionnaire responses, tier vendors, and run periodic control reviews—not one-time audit cramming.

See `references/vendor_and_continuous_compliance.md`.

Outputs

• Compliance scope memo — frameworks, systems, data, exclusions, calendar
• Control matrix — requirement ID, owner, policy/procedure, evidence type, status
• Gap and remediation plan — priority, due date, dependency on engineering/legal
• Policy/procedure outlines — sections ready for approval workflow
• Audit prep pack — agenda, FAQ, request tracker, exception log
• Questionnaire response library — approved answers with evidence links

Principles

• Program before tooling — scope and owners before collectors
• Separate GRC from build — this skill defines what to prove; compliance-engineer automates how
• No legal advice — cite requirements; escalate interpretation to counsel
• Evidence pointers, not screenshots hoards — name systems of record and owners
• Continuous cadence — quarterly reviews beat pre-audit fire drills

When to load references

Audit and assessor coordination

Table of contents

1. Pre-audit timeline 2. Request management 3. Walkthrough preparation 4. During the audit 5. Post-audit

Pre-audit timeline

Align observation period start with stable control operation—avoid major releases without change record.

Request management

Use a request tracker (spreadsheet or GRC tool):

Rules:

• One submission per request unless auditor splits
• Legal or HR-sensitive items — counsel review before send
• No ad-hoc email attachments without tracker entry

Walkthrough preparation

Per session (60–90 minutes typical):

1. Objective — control families covered 2. Attendees — compliance lead, control owner SME, scribe 3. Agenda — narrative flow matching control matrix order 4. Demo script — if live system demo required, limit to read-only views 5. Evidence pack — pre-staged links opened and tested 6. FAQ — shared responsibility, subprocessors, encryption, logging retention

Prepare bridge documents where logs alone are insufficient (one page max, factual).

Coordinate cloud-specific sessions with cloud-compliance-specialist.

During the audit

• Daily internal sync — open items, blockers, clarifications needed
• Single point of contact to auditors; SMEs speak to their domain only
• Log all verbal commitments; confirm in writing same day
• Escalate scope creep to program sponsor before agreeing to new populations

Do not debate legal interpretation in walkthroughs—defer to commercial-counsel.

Post-audit

1. Draft management response to findings (owner, date, action) 2. Update control matrix status and remediation plan 3. Feed findings into security-risk-analyst register if material 4. Schedule lessons learned — evidence gaps, tooling needs for compliance-engineer 5. Plan surveillance or annual recertification calendar

Store final report and letter of opinion in controlled repository with access log.

Compliance specialist scope

Table of contents

1. Role boundary 2. Program charter 3. Stakeholders and RACI 4. Deliverables

Role boundary

Do not provide legal conclusions, attest on behalf of the company, or implement infrastructure.

Program charter

Capture in one page:

• Objectives — customer contracts, market entry, insurance, board mandate
• Frameworks in scope — e.g., SOC 2 TSC, ISO 27001 Annex A subset, HIPAA safeguards, PCI SAQ level
• Systems and environments — prod vs non-prod, SaaS vs on-prem, geographies
• Data classes — PII, PHI, PCI CHD, confidential IP
• Calendar — target report date, observation period, internal mock-audit dates
• Success criteria — clean opinion, no material exceptions, customer questionnaire turnaround SLA

Revisit charter when product, M&A, or major vendor changes occur.

Stakeholders and RACI

Assign one named owner per control family (access, change, vuln, logging, vendors).

Deliverables

Minimum viable program artifacts:

1. Scope memo (approved) 2. Control matrix with status (implemented / partial / gap / N/A) 3. Gap remediation plan with dates 4. Policy index with version and approver 5. Exception register with expiry 6. Audit request tracker 7. Vendor tier list and review schedule

Hand off technical evidence build to compliance-engineer once matrix columns for evidence source and automation are defined.

Framework scoping and mapping

Table of contents

1. Framework selection 2. Scoping decisions 3. Control matrix structure 4. Common mappings

Framework selection

Select one primary framework for the first certification cycle; map others as overlays to avoid duplicate work.

Scoping decisions

Document explicitly:

• Legal entities and brands covered by report
• Products and services in scope (version, region)
• Environments — production only vs include staging with customer data
• Subprocessors — list with function, data types, region
• Exclusions — legacy systems, acquired units, dev laptops without prod access
• Trust criteria / control families out of scope with approver sign-off

Refresh scope when launching new regions, AI features processing personal data, or material vendor changes.

Control matrix structure

Use one row per control requirement with columns:

Keep implementation detail in engineering runbooks; matrix stays assessor-readable.

Common mappings

SOC 2 ↔ ISO 27001 (illustrative)

Many organizations map:

• CC6 (logical access) ↔ A.5, A.8 identity and access
• CC7 (system operations) ↔ A.8 operations security
• CC8 (change management) ↔ A.8 change control
• C1 (confidentiality) ↔ A.5 information classification

Maintain a crosswalk tab only where dual reporting is required; do not maintain two conflicting definitions of the same control.

HIPAA ↔ SOC 2

Map administrative, physical, and technical safeguards to TSC where customers ask for both. Flag gaps where HIPAA requires elements not in selected TSC (document compensating narrative).

PCI scoping

Confirm CDE boundaries, connected systems, and segmentation evidence requirements early. Engage cloud-compliance-specialist when CDE is in cloud.

Escalate novel regulatory questions to commercial-counsel; do not interpret statute.

Gap assessment and remediation planning

Table of contents

1. Assessment method 2. Gap classification 3. Remediation plan 4. Exceptions and risk acceptance

Assessment method

1. Baseline — approved policies, prior audit reports, customer questionnaires, incident history 2. Walkthroughs — interview control owners; sample one evidence artifact per family 3. Technical spot-check — request read-only exports; do not configure systems in this role 4. Score each requirement against matrix status 5. Validate fixes with re-assessment and linked evidence ticket

Run mock assessment 60–90 days before external audit; treat findings like real audit items.

Gap classification

Tag gaps with severity:

• Critical — blocks audit opinion or customer contract
• High — likely finding; customer-facing
• Medium — should fix before observation end
• Low — hygiene; batch with other work

Remediation plan

Each gap row includes:

Route engineering work to compliance-engineer with acceptance criteria copied from evidence plan.

Review remediation plan weekly in program standup; escalate overdue critical items to executive sponsor.

Exceptions and risk acceptance

Maintain an exception register:

• Control ID and description of deviation
• Business justification
• Compensating controls
• Approver (role per policy)
• Expiry date (max 12 months unless renewed)
• Re-review trigger (incident, audit, architecture change)

Never leave exceptions verbal-only; auditors will request the register.

Policies, procedures, and evidence

Table of contents

1. Policy hierarchy 2. Procedure outlines 3. Evidence requirements 4. Quality rules

Policy hierarchy

Draft outlines for approval; legal or policy committee owns final language.

Minimum policy set for SOC 2 / ISO-style programs:

• Information security
• Acceptable use
• Access control
• Change management
• Incident response
• Vendor / third-party risk
• Business continuity / disaster recovery
• Data classification and handling
• Risk management (may align with security-risk-analyst register)

Version every document: number, date, approver, next review date (annual typical).

Procedure outlines

For each in-scope control family, procedure outline includes:

1. Purpose and scope 2. Roles — requester, approver, administrator 3. Triggers — hire, termination, production change, vulnerability SLA breach 4. Steps — numbered, testable 5. Records — ticket IDs, logs, sign-offs 6. Exceptions — escalation path 7. Review cadence

Example families: user access provisioning/review, privileged access, change approval, vulnerability remediation, backup restore test, security awareness training.

Evidence requirements

Define evidence at the requirement level before automation:

Distinguish:

• Program evidence — policy approval, risk acceptance, org chart
• Operating evidence — logs, tickets, reviews showing control operated
• Technical evidence — configs and API exports (compliance-engineer, cloud-compliance-specialist)

Quality rules

Reject evidence that is:

• Undated or screenshot-only without system metadata
• Missing population definition for sample-based controls
• Prepared only for audit with no operating history
• Owned by unnamed "IT" without accountable individual

Prefer primary sources (tickets, IdP, CI) over narrative memos.

Vendor and continuous compliance

Table of contents

1. Vendor risk tiers 2. Questionnaire workflow 3. Response library 4. Continuous compliance program 5. Metrics and reporting

Vendor risk tiers

Document tier rationale. Align subprocessors list with SOC/ISO scope memo.

Questionnaire workflow

1. Intake — SIG, CAIQ, custom Excel, customer security portal 2. Triage — due date, customer revenue tier, repeating vs net-new 3. Assign — compliance-specialist coordinates; SMEs answer domain sections 4. Consistency check — compare to approved response library; flag conflicts 5. Evidence attach — link SOC report (under NDA), pen test summary, policies index 6. Approval — security lead or delegate before customer send 7. Archive — version, date, approver for reuse

Legal sections (indemnity, DPA terms) → commercial-counsel, not compliance-specialist alone.

Technical assertions (encryption, logging) → validate with information-security-engineer or cloud-security-engineer.

Response library

Maintain approved answers for common themes:

• Organizational security governance
• Access control and MFA
• Change and release management
• Vulnerability and patch management
• Incident response and breach notification process (not legal advice)
• BCP/DR and backups
• Subprocessor list and locations
• Certifications in scope (SOC 2, ISO) with report date

Each entry: answer text, last reviewed date, evidence pointer, owner.

When library answer is stale (>6 months or post-incident), block reuse until refresh.

Continuous compliance program

Shift from point-in-time audit to operating rhythm:

Integrate drift detection and automated collectors via compliance-engineer once matrix defines sources.

Cloud posture dashboards → cloud-compliance-specialist.

Metrics and reporting

Executive dashboard (keep small):

• % controls implemented vs in-scope
• Open gaps by severity and age
• Overdue remediations
• Exceptions past expiry (target zero)
• Customer questionnaire turnaround time
• Audit readiness score (mock assessment trend)

Tie metrics to risk appetite discussion with security-risk-analyst and cybersecurity; do not optimize vanity percentages without risk context.