# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Overview

This is the official open-source Claude Code plugin marketplace of the [GRC Engineering Club](https://grcengclub.com) for Governance, Risk, and Compliance (GRC) professionals. `.claude-plugin/marketplace.json` is the authoritative plugin list; the categories below describe the shapes, not an exhaustive inventory.

- **Persona plugins** (grc-engineer, grc-auditor, grc-internal, grc-tprm)
- **Framework plugins** under `plugins/frameworks/` (soc2, nist-800-53, iso27001, fedramp-rev5, fedramp-20x, pci-dss, cmmc, and more) — see [docs/FRAMEWORK-COVERAGE.md](docs/FRAMEWORK-COVERAGE.md) for the generated list
- **Connector plugins** under `plugins/connectors/` (aws-inspector, gcp-inspector, github-inspector, okta-inspector, and more) that emit findings matching `schemas/finding.schema.json`
- **OSCAL tooling plugins** (oscal, fedramp-ssp) wrapping external upstream projects
- **Reporting and workflow plugins** (grc-reporter, grc-loop, grc-diagrams, teach-me, trust-center, compliance-posture-dashboard)
- **grc-portfolio** — site-builder plugin that scaffolds and deploys a GRC engineer's portfolio website (React/Vite on S3 + CloudFront, optional Route 53/ACM and SES-backed contact form, GitHub Actions OIDC for CI/CD)

Each plugin contains commands (user-facing) and skills (AI agents that implement functionality).

## Architecture

### Plugin Structure

All plugins follow this structure:

```
plugins/{plugin-name}/
├── .claude-plugin/
│   └── plugin.json              # Plugin metadata (name, version, author)
├── commands/                    # User-facing commands (markdown files)
│   └── {command-name}.md        # Command documentation and instructions
├── skills/                      # AI agents that implement functionality
│   └── {skill-name}/
│       └── SKILL.md            # Skill prompt and behavior definition
├── config/                      # Configuration files (grc-engineer only)
│   ├── frameworks/             # Framework control mappings (YAML)
│   └── providers/              # Cloud provider templates (AWS, Azure, GCP, K8s)
└── scripts/                     # Node.js implementation scripts (grc-engineer only)
    └── {command-name}.js       # Command logic
```

### Two Plugin Patterns

**1. Script-backed plugins (grc-engineer, the connectors, `fedramp-20x`, `dashboards/compliance-posture`, `knowledge-sources/gcp-docs`)**

- Include `scripts/` directory with Node.js implementations
- Include `config/` directory with YAML configurations (where needed)
- Commands invoke scripts: `node scripts/map-control.js $ARGUMENTS`

**2. Prompt-only plugins (soc2, nist-800-53, iso27001, grc-auditor, grc-internal, grc-tprm, etc.)**

- Command files are self-contained with embedded instructions
- No scripts or config directories
- Skills contain expertise as prompts

The persona plugins split across both patterns: `grc-engineer` is script-backed, while `grc-auditor`, `grc-internal`, and `grc-tprm` are prompt-only.

### Key Directories

- `.claude-plugin/marketplace.json` - Marketplace configuration listing all plugins
- `plugins/grc-engineer/config/frameworks/` - Framework control definitions (SOC2, ISO27001, NIST 800-53, etc.)
- `plugins/grc-engineer/config/providers/` - Cloud provider evidence collection templates (aws.yaml, azure.yaml, gcp.yaml, kubernetes.yaml)
- `docs/ENTERPRISE-DEPLOYMENT.md` - AWS Bedrock, Claude Platform on AWS, and Google Vertex AI deployment guidance

## Plugin Development

### Adding a New Framework Plugin

Framework plugins are lightweight and follow this pattern:

1. Create directory: `plugins/frameworks/{framework-name}/`
2. Add plugin.json with metadata
3. Create commands as markdown files with instructions
4. Create skills with framework expertise
5. Register in `.claude-plugin/marketplace.json`

Example: See `plugins/frameworks/soc2/` or `plugins/frameworks/pci-dss/`

### Adding a New Command to grc-engineer

1. Create command file: `plugins/grc-engineer/commands/{command}.md`
2. Create script: `plugins/grc-engineer/scripts/{command}.js`
3. If needed, add framework config: `plugins/grc-engineer/config/frameworks/{framework}.yaml`
4. Create skill: `plugins/grc-engineer/skills/{skill-name}/SKILL.md`

### Configuration File Patterns

**Framework configs** (`config/frameworks/*.yaml`):

```yaml
controls:
  CC6.1:
    title: Logical and Physical Access Controls
    keywords: [iam, access control, authentication]
```

**Provider templates** (`config/providers/*.yaml`):

```yaml
templates:
  mfa_root:
    keywords: [mfa, root]
    formats:
      python: |
        import boto3
        # Evidence collection script
      bash: |
        aws iam get-account-summary
```

## Testing Plugins

### Local Testing

```bash
# Clone and run with local plugins
git clone https://github.com/GRCEngClub/claude-grc-engineering.git
claude --plugin-dir ./claude-grc-engineering
```

### Testing Specific Commands

```bash
# Test grc-engineer command
/grc-engineer:map-control main.tf SOC2

# Test framework command
/soc2:assess detailed

# Test evidence collection
/grc-engineer:collect-evidence CC6.1 AWS python
```

## Enterprise Deployment

This repository supports enterprise deployments via AWS Bedrock and Google Vertex AI. See `docs/ENTERPRISE-DEPLOYMENT.md` for:

- AWS Bedrock configuration (FedRAMP High in GovCloud)
- Google Vertex AI configuration (FedRAMP High as of October 2025)
- IAM permissions and authentication
- Compliance certifications (HIPAA, SOC 2)

Configuration via environment variables:

```bash
# AWS Bedrock
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1

# Google Vertex AI
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=us-east5
export ANTHROPIC_VERTEX_PROJECT_ID=your-project-id
```

## Marketplace Installation

Users install plugins via:

```bash
# Add marketplace (one-time)
/plugin marketplace add GRCEngClub/claude-grc-engineering

# Install specific plugins
/plugin install grc-engineer@grc-engineering-suite
/plugin install soc2@grc-engineering-suite
```

## Plugin Namespaces

Each plugin has a unique namespace for commands:

- `/grc-engineer:` - Technical compliance automation
- `/grc-auditor:` - Audit and assessment tools
- `/grc-internal:` - Internal GRC team tools
- `/grc-tprm:` - Third-party risk management
- `/grc-portfolio:` - GRC engineer portfolio site builder (plan → build → preflight → infra → deploy → repo → cicd)
- `/academic-research-companion:` - Academic research lifecycle companion (idea → literature → methodology → writing → feedback → publishing → authorship)
- `/soc2:` - SOC 2 expertise
- `/nist:` - NIST 800-53 controls
- `/iso:` - ISO 27001 ISMS
- `/fedramp-rev5:` - Traditional FedRAMP
- `/fedramp-20x:` - Modern FedRAMP with auto-sync
- `/pci-dss:` - PCI DSS v4.0.1
- `/us-export:` - US Export Controls (ITAR + EAR)
- `/pbmm:` - Canadian Protected B cloud
- `/ismap:` - Japanese government cloud
- `/irap:` - Australian government cloud
- (plus the remaining framework plugins under `plugins/frameworks/`; [docs/FRAMEWORK-COVERAGE.md](docs/FRAMEWORK-COVERAGE.md) lists them all)

## Cross-Framework Intelligence (NEW)

The grc-engineer plugin now includes advanced cross-framework intelligence capabilities that reduce implementation effort by 56% on average.

### Key Features

**Control Crosswalk Database** (`plugins/grc-engineer/config/control-crosswalk.yaml`):

- Maps 300+ controls across 7+ frameworks (SOC2, PCI-DSS, NIST, ISO, CIS, CMMC, FedRAMP)
- Identifies "implement once, satisfy many" opportunities
- Documents conflicting requirements and resolutions
- Provides multi-cloud implementation patterns

**Cross-Framework Analysis Script** (`plugins/grc-engineer/scripts/cross-framework-analyzer.js`):

- Node.js module for analyzing control overlaps
- Parses YAML crosswalk database
- Calculates optimization tiers (Tier 1: satisfies 4+ frameworks, Tier 2: 3 frameworks, etc.)
- Generates implementation roadmaps with effort estimates

### New Commands

1. **`/grc-engineer:map-controls-unified <control>`**
   - Maps a single control across ALL frameworks
   - Shows framework equivalencies (e.g., NIST AC-2 = ISO A.9.2 = SOC2 CC6.1)
   - Identifies conflicts and resolutions
   - Provides cloud implementation patterns

2. **`/grc-engineer:find-conflicts <frameworks> [detail-level]`**
   - Analyzes conflicting requirements across selected frameworks
   - Categorizes by severity (high/medium/low)
   - Provides resolution strategies ("most restrictive wins")
   - Example: `find-conflicts SOC2,PCI-DSS,NIST detailed`

3. **`/grc-engineer:optimize-multi-framework <frameworks> [format]`**
   - Generates optimization roadmap showing effort reduction
   - Categorizes controls into 4 tiers by ROI
   - Provides phased implementation plan
   - Shows quick wins (high value, low effort)
   - Formats: roadmap (default), matrix (CSV), summary
   - Example: `optimize-multi-framework SOC2,PCI-DSS,NIST,ISO`

### Optimization Results

Typical multi-framework optimization (SOC2 + PCI-DSS + NIST + ISO):

- **Without optimization**: 815 controls × 8 hours = 6,520 hours
- **With optimization**: 362 unique controls = 2,896 hours
- **Savings**: 3,624 hours (56%) = ~$543,600 at $150/hour

**Tier Breakdown**:

- Tier 1 (4+ frameworks): 87 controls, 40% coverage, 4× ROI
- Tier 2 (3 frameworks): 124 controls, +35% coverage, 3× ROI
- Tier 3 (2 frameworks): 89 controls, +17% coverage, 2× ROI
- Tier 4 (framework-specific): 62 controls, +8% coverage, 1× ROI

### Example Usage

```bash
# Understand cross-framework control mapping
/grc-engineer:map-controls-unified access_control_account_management

# Identify conflicts between 3 frameworks
/grc-engineer:find-conflicts SOC2,PCI-DSS,NIST

# Generate optimization roadmap for 4 frameworks
/grc-engineer:optimize-multi-framework SOC2,PCI-DSS,NIST,ISO roadmap

# Export control matrix as CSV
/grc-engineer:optimize-multi-framework SOC2,PCI-DSS,NIST matrix

# Generate implementation code
/grc-engineer:generate-implementation access_control_account_management aws

# Scan infrastructure for violations
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST detailed --fix

# Test control effectiveness
/grc-engineer:test-control access_control_account_management aws

# Set up continuous monitoring
/grc-engineer:monitor-continuous SOC2,PCI-DSS,NIST daily --slack-webhook=URL
```

### Extending the Crosswalk

To add new controls to the crosswalk database:

1. Edit `plugins/grc-engineer/config/control-crosswalk.yaml`
2. Add control with framework mappings:

```yaml
controls:
  my_new_control:
    name: Descriptive Control Name
    category: Security Category

    nist_800_53: [AC-X, AC-X(1)]
    iso_27001: [A.X.Y.Z]
    soc2: [CC.X]
    pci_dss: [X.Y]

    common_requirements:
      - Requirement 1
      - Requirement 2

    conflicts:
      - name: Conflict Description
        framework1: "Requirement text"
        framework2: "Different requirement text"
        resolution: "How to resolve"

    cloud_implementation:
      aws: |
        Implementation guidance for AWS
      azure: |
        Implementation guidance for Azure
```

3. Test with:

```bash
node plugins/grc-engineer/scripts/cross-framework-analyzer.js map my_new_control
```

## Code Generation & IaC Scanning (NEW - Phase 2)

The grc-engineer plugin now includes production-ready code generation and infrastructure scanning capabilities.

### Code Generation

**Command**: `/grc-engineer:generate-implementation <control> <cloud-provider> [output-dir]`

Generates complete implementation packages including:

- **Terraform modules**: Production-ready IaC with best practices
- **Python scripts**: Evidence collection, compliance testing, automation
- **Monitoring dashboards**: CloudWatch, Azure Monitor, or Google Cloud Monitoring
- **Documentation**: Implementation guides, evidence procedures, framework mappings

**Example Output** (for `access_control_account_management` on AWS):

```
generated/
├── terraform/
│   ├── main.tf (300 lines)       # IAM lifecycle, CloudTrail, Access Analyzer
│   ├── variables.tf               # Configurable parameters
│   ├── outputs.tf                 # Resource outputs
│   └── providers.tf               # AWS provider config
├── scripts/
│   ├── evidence_collect.py        # Automated evidence collection
│   ├── compliance_test.py         # Validation tests
│   └── deploy.sh                  # Deployment automation
├── monitoring/
│   └── dashboard.json             # CloudWatch dashboard
└── docs/
    ├── IMPLEMENTATION.md          # Complete deployment guide
    ├── EVIDENCE.md                # Collection procedures
    └── FRAMEWORKS.md              # Framework requirement mappings
```

**Cloud Provider Support**:

- `aws` - AWS with CloudTrail, IAM, KMS, CloudWatch
- `azure` - Azure with Azure AD, Key Vault, Monitor
- `gcp` - GCP with Cloud IAM, KMS, Logging
- `kubernetes` - K8s with RBAC, NetworkPolicy, PodSecurityPolicy

**Usage Example**:

```bash
# Generate for AWS
/grc-engineer:generate-implementation encryption_at_rest aws ./compliance

# Output includes:
# - S3 bucket encryption configuration
# - KMS key setup with rotation
# - EBS encryption defaults
# - RDS encryption settings
# - Evidence collection scripts
```

### IaC Scanning

**Command**: `/grc-engineer:scan-iac <directory> <frameworks> [format] [options]`

**Script**: `plugins/grc-engineer/scripts/scan-iac.js`

Scans existing infrastructure code for compliance violations:

**Supported Formats**:

- Terraform (`.tf` files)
- CloudFormation (`.yaml`, `.json`)
- Kubernetes (`.yaml` manifests)
- Azure ARM templates (`.json`)

**Compliance Checks**:

- **Encryption at Rest**: S3, EBS, RDS encryption configuration
- **Logging & Monitoring**: CloudTrail, VPC Flow Logs, retention periods
- **Network Security**: Security groups, overly permissive rules
- **Access Control**: IAM policies, least privilege violations
- **Data Protection**: S3 versioning, public access blocks

**Output Formats**:

- `detailed` - Full analysis with remediation code (default)
- `summary` - Quick compliance score and top issues
- `json` - Machine-readable for CI/CD
- `sarif` - GitHub Security / GitLab integration

**Auto-Fix Mode**:

```bash
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS --fix
```

Automatically remediates:

- ✓ Missing S3 bucket encryption
- ✓ Disabled S3 versioning
- ✓ Missing S3 public access blocks
- ✓ Disabled KMS key rotation
- ✓ Short log retention periods
- ✗ Security group rules (requires manual review)
- ✗ IAM policies (security sensitive)

**CI/CD Integration**:

GitHub Actions:

```yaml
- name: Scan Infrastructure
  run: /grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST sarif > results.sarif

- name: Upload Results
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: results.sarif
```

**Severity Levels**:

- 🔴 CRITICAL: Immediate violation, blocks audit
- 🟡 HIGH: Serious gap, fix before audit
- 🟠 MEDIUM: Important improvement
- 🔵 LOW: Best practice recommendation

**Example Scan Output**:

```
Scan Target: ./terraform
Frameworks: SOC2, PCI-DSS, NIST 800-53
Files Scanned: 23

Compliance: 73% (42/57 controls)

Violations:
  🔴 HIGH (3):
    - S3 bucket encryption missing (s3_buckets.tf:12)
    - CloudTrail retention too short (cloudtrail.tf:8)
    - Security group too permissive (security_groups.tf:24)

  🟡 MEDIUM (5):
    - Missing patch management configuration
    - Root account MFA not verified
    ...

Auto-fix available for 8/15 violations
```

### Implementation Workflow

**1. Design Phase**:

```bash
# Understand requirements across frameworks
/grc-engineer:map-controls-unified access_control_account_management

# Identify conflicts
/grc-engineer:find-conflicts SOC2,PCI-DSS,NIST

# Get optimization roadmap
/grc-engineer:optimize-multi-framework SOC2,PCI-DSS,NIST
```

**2. Implementation Phase**:

```bash
# Generate production-ready code
/grc-engineer:generate-implementation access_control_account_management aws ./output

# Review and customize
cd ./output/terraform
terraform init
terraform plan
```

**3. Validation Phase**:

```bash
# Scan for compliance violations
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST detailed

# Apply fixes
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST --fix

# Verify compliance
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST summary
```

**4. Evidence Collection**:

```bash
# Collect compliance evidence
cd ./output/scripts
python evidence_collect.py ./evidence/2025-Q1
```

## Control Testing & Monitoring (NEW - Phase 3)

The grc-engineer plugin now includes automated control testing and continuous monitoring to ensure controls remain effective over time.

### Control Testing

**Command**: `/grc-engineer:test-control <control-id> [cloud-provider] [options]`

**Script**: `plugins/grc-engineer/scripts/test-control.js`

Validates that security controls are properly implemented and effective:

**Test Categories**:

1. **Configuration Tests**: Resources exist and configured correctly
2. **Functionality Tests**: Controls are active and working
3. **Compliance Tests**: Meet framework requirements
4. **Integration Tests**: Work with other controls

**Example Test Run** (`access_control_account_management` on AWS):

```
Total Tests: 15
✓ Passed: 11 (73%)
✗ Failed: 2 (13%)
⚠ Warnings: 2 (13%)

FAILURES:
- Quarterly access review overdue (92 days, PCI requires 90)
- Access review policy documentation outdated

FRAMEWORK COMPLIANCE:
NIST 800-53: ⚠ PARTIALLY COMPLIANT
ISO 27001:   ⚠ PARTIALLY COMPLIANT
SOC2:        ⚠ PARTIALLY COMPLIANT
PCI-DSS:     ✗ NON-COMPLIANT (quarterly review requirement violated)

Status: PARTIALLY EFFECTIVE
Remediation: Run python scripts/access_review.py --immediate
```

**Test Types by Control**:

**Access Control** (15 tests):

- ✓ Unique user IDs
- ✓ Access approval process
- ✗ Quarterly access reviews (schedule/execution)
- ✓ Automated provisioning
- ✓ Least privilege (permissions boundaries)
- ✓ CloudTrail logging active
- ⚠ Inactive user detection (>90 days)
- ✓ Access Analyzer enabled
- ✓ MFA enforcement
- ✓ Audit trail integrity
- ✓ Log retention period (365 days)
- ✓ Separation of duties
- ✓ Evidence availability
- ✗ Documentation currency
- ✓ End-to-end lifecycle

**Encryption at Rest** (tests):

- S3 bucket encryption
- EBS volume encryption
- RDS database encryption
- KMS key rotation enabled

**Logging & Monitoring** (tests):

- CloudTrail configuration
- VPC Flow Logs
- Log retention compliance
- CloudWatch alarms

**Output Formats**:

- `text` - Detailed human-readable (default)
- `json` - Machine-readable for CI/CD
- `--verbose` - Include all test details
- `--fix-failures` - Auto-remediate where possible

**CI/CD Integration**:

```yaml
- name: Test Access Control
  run: /grc-engineer:test-control access_control_account_management --output=json > results.json

- name: Check Pass Rate
  run: |
    PASS_RATE=$(jq '.summary.pass_rate' results.json)
    if (( $(echo "$PASS_RATE < 0.90" | bc -l) )); then
      exit 1
    fi
```

### Continuous Monitoring

**Command**: `/grc-engineer:monitor-continuous <frameworks> [schedule] [options]`

Establishes continuous compliance monitoring with:

**Features**:

1. **Automated Testing**: Runs control tests on schedule (daily, weekly, hourly)
2. **Trend Analysis**: 30-day compliance trends with degradation detection
3. **Alerting**: Slack, email, or PagerDuty integration
4. **Dashboard**: Real-time compliance status visualization

**Example Monitoring Output**:

```
COMPLIANCE TREND (Last 30 Days):
Jan 1:  95% ████████████████████░
Jan 8:  94% ████████████████████░  ⚠ -1%
Jan 15: 94% ████████████████████░  → Stable
Jan 22: 96% █████████████████████  ✓ +2%
Jan 28: 96% █████████████████████  → Stable

Trend: ↗ IMPROVING (+1% this month)

CURRENT STATUS:
Overall: 96% (144/150 controls)

By Framework:
  SOC2:       98% ████████████████████░
  PCI-DSS:    92% ███████████████████░░
  NIST 800-53: 98% ████████████████████░

RECENT FAILURES:
🔴 HIGH: AU-11 (Audit Retention) - S3 lifecycle misconfigured
🟡 MED: AC-2 (Account Mgmt) - 3 inactive users detected

CONTROL HEALTH:
🟢 HEALTHY: 138 controls (30-day pass rate >95%)
🟡 DEGRADING: SI-2 (Vuln Mgmt) - 93% → 87% (-6%)
🔴 AT RISK: AU-11 (Audit Retention) - 73% pass rate
```

**Alerting Rules**:

- 🚨 **Critical**: Compliance <80%, control fails 2+ days, PCI <90%
- ⚠ **Warning**: Compliance 80-90%, degrading controls (-5% in 7 days)
- ℹ **Info**: Weekly summary, trending analysis

**Setup**:

```yaml
# compliance-monitor.yaml
frameworks: [SOC2, PCI-DSS, NIST-800-53]
schedule:
  full_test: "0 2 * * *"      # Daily 2 AM
  quick_check: "0 */6 * * *"  # Every 6 hours

alerts:
  slack:
    webhook_url: "https://hooks.slack.com/..."
    channel: "#security-alerts"
  email:
    recipients: [security@company.com]

thresholds:
  critical: 0.80  # Alert if <80%
  warning: 0.90   # Warn if <90%
```

**Metrics Tracked**:

- Compliance score (% passing controls)
- Framework scores (individual)
- Control health (30-day pass rate)
- Test execution time
- Failure rate
- Remediation time
- Evidence coverage

**Dashboard Features**:

- Real-time compliance status
- 30-day trend visualization
- Control health indicators (green/yellow/red)
- Framework comparison
- Recent failures with remediation
- Alert history

### Complete Workflow (All 3 Phases)

**Phase 1 - Design**:

```bash
/grc-engineer:map-controls-unified access_control_account_management
/grc-engineer:find-conflicts SOC2,PCI-DSS,NIST
/grc-engineer:optimize-multi-framework SOC2,PCI-DSS,NIST,ISO
```

**Phase 2 - Implement**:

```bash
/grc-engineer:generate-implementation access_control_account_management aws
cd generated/terraform && terraform apply
/grc-engineer:scan-iac ./terraform SOC2,PCI-DSS,NIST --fix
```

**Phase 3 - Validate & Monitor**:

```bash
/grc-engineer:test-control access_control_account_management aws
/grc-engineer:monitor-continuous SOC2,PCI-DSS,NIST daily
```

This provides end-to-end compliance automation:

1. **Understand** requirements across frameworks (crosswalk)
2. **Optimize** implementation (56% effort reduction)
3. **Generate** production code (Terraform, scripts)
4. **Scan** existing infrastructure (violations + fixes)
5. **Test** control effectiveness (config, functionality, compliance)
6. **Monitor** continuously (trends, alerts, dashboard)

## Access Review Triage (NEW)

The grc-engineer plugin includes an `access-review-triage` skill for teams running quarterly user access reviews (UARs) out of spreadsheets — the common shape for orgs without a dedicated IGA tool (Sailpoint, Saviynt, Okta Access Certifications).

Lives at `plugins/grc-engineer/skills/access-review-triage/SKILL.md`. The skill takes a CSV or JSON access export (Okta, Azure AD, AWS IAM, GitHub, or generic) plus optional HR list, SoD config, and prior-cycle decisions, then walks 10 ordered decision rules to tag each row:

- Rule 1: terminated user with active access → Investigate (P0)
- Rule 2: separation-of-duty conflict → Investigate (P0)
- Rule 3: dormant admin (last_login > 90 days) → Investigate (P1)
- Rule 4: dormant non-privileged user → Revoke (suggested)
- Rule 5: service / shared account in human review → Investigate (P1)
- Rule 6: role-vs-title mismatch → Manager confirm
- Rule 7: new since last cycle → Manager confirm
- Rule 8: privileged role (catch-all) → Manager confirm
- Rule 9: unchanged since last cycle → Auto-certify
- Rule 10: default → Manager confirm

Output is four artifacts in `~/.cache/claude-grc/access-reviews/<system>-<YYYY-QN>/`: `triage.md` (human-readable report), `decisions.csv` (machine-readable per-row recommendations), `manager-emails/<manager>.md` (drafted confirmation emails), and `evidence.json` (audit-binder packet with control mappings to SOC 2 CC6.1/CC6.2, PCI 7-8, ISO A.9, NIST AC-2).

The skill never auto-revokes — every recommendation is a draft for human review. It refuses to run for orgs that already have an IGA tool unless `--force` is passed.

## Multi-Cloud Support

The grc-engineer plugin supports evidence collection across:

- **AWS**: boto3, aws CLI (IAM, S3, CloudTrail)
- **Azure**: azure-* SDKs, az CLI (AD, Storage, Monitor)
- **GCP**: google-cloud-* SDKs, gcloud CLI (IAM, Storage, Logging)
- **Kubernetes**: kubectl, kubernetes SDK

## Issue tracking (Linear)

This repo ships a **project-scoped** Linear MCP server in `.mcp.json` named `linear-grc-club`, pointing at `https://mcp.linear.app/mcp`. It loads only when Claude Code starts in this directory and does not affect MCP configuration in any other repo.

**First-time setup per machine:**

1. Start a Claude Code session in this directory.
2. Run `/mcp` and authenticate `linear-grc-club` via OAuth.
3. **Select the GRC Engineering Club workspace** at the consent screen (not a personal Linear). OAuth tokens are stored in the user's Claude config, not in the repo.

Linear operations from this repo should target the GRC Engineering Club workspace through the `linear-grc-club` MCP. If a global `claude.ai Linear` MCP is also active in the session (authenticated to a different workspace), prefer the project-scoped tools so issues land in the right workspace.

**Default Linear scope for toolkit work:**

- **Team**: `GRC Engineering Club` (key `GRC`) — ID `f11daee3-f05b-4410-bcee-2e76df7acb91`
- **Project (default for toolkit issues)**: [`Claude GRC Engineering Toolkit`](https://linear.app/grc-engineering-club/project/claude-grc-engineering-toolkit-8f6001008c85) — ID `f6ae9cc5-5bfc-496b-b938-c00fe51bafbe`

Day-to-day bug reports and feature requests should still be filed as GitHub issues on this repo. Use the Linear project for cross-cutting toolkit work — roadmap, RFCs, releases, contributor coordination, and threads that span multiple GitHub issues.

## Important Notes

- Plugins are MIT licensed, except `cis-controls`, which is `CC-BY-SA-4.0 AND MIT`
- Plugin versions are synchronized at 0.1.0
- Framework control mappings are in YAML for easy extension
- Most framework plugins are pure markdown/prompt-based; `fedramp-20x` is the exception and ships `check-fedramp-updates.js`
- Node.js scripts live in `grc-engineer`, every connector, `dashboards/compliance-posture`, and `knowledge-sources/gcp-docs`. `grc-auditor`, `grc-internal`, and `grc-tprm` are prompt-only despite being personas