/find-conflicts

description: Identify conflicting requirements across frameworks

Find Conflicts

Analyzes your selected compliance frameworks to identify conflicting requirements and provides resolution strategies.

Usage

/grc-engineer:find-conflicts <frameworks> [detail-level]

Arguments

• `$1` - Comma-separated list of frameworks (e.g., "SOC2,PCI-DSS,NIST")
• `$2` - Detail level (optional): "summary" or "detailed" (default: "detailed")

Framework Codes

• `SOC2` - SOC 2 Trust Service Criteria
• `NIST` - NIST 800-53
• `ISO` - ISO 27001
• `PCI` or `PCI-DSS` - PCI DSS
• `CIS` - CIS Controls
• `CMMC` - CMMC 2.0
• `FedRAMP` - FedRAMP (Rev 5 or 20X)
• `HITRUST` - HITRUST CSF
• `GDPR` - GDPR

Examples

# Find conflicts between SOC2 and PCI-DSS
/grc-engineer:find-conflicts SOC2,PCI-DSS

# Detailed analysis across multiple frameworks
/grc-engineer:find-conflicts SOC2,PCI-DSS,NIST,ISO detailed

# Summary view for quick review
/grc-engineer:find-conflicts NIST,FedRAMP,CMMC summary

Output

The command provides:

1. **Conflict Summary**: Number and severity of conflicts 2. **Detailed Conflicts**: Specific requirement differences 3. **Resolution Strategy**: Recommended approach to satisfy all frameworks 4. **Implementation Guidance**: How to configure to meet all requirements

Example Output

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CROSS-FRAMEWORK CONFLICT ANALYSIS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Frameworks Analyzed: SOC2, PCI-DSS, NIST 800-53, ISO 27001
Controls Analyzed: 87 overlapping controls

CONFLICT SUMMARY:
  🔴 High Severity: 3 conflicts (require immediate attention)
  🟡 Medium Severity: 7 conflicts (may need adjustment)
  🟢 Low Severity: 12 conflicts (minor differences)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
HIGH SEVERITY CONFLICTS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔴 CONFLICT #1: Access Review Frequency
   Control Area: Account Management
   Affected Controls: NIST AC-2, ISO A.9.2.5, SOC2 CC6.1, PCI 8.1.4

   Requirements:
   - SOC2:    No specific frequency, risk-based approach
              (typically quarterly for sensitive systems)
   - PCI-DSS: Quarterly reviews MANDATORY (every 90 days)
              Requirement 8.1.4: At least quarterly
   - NIST:    Annually minimum, or when roles/responsibilities change
              AC-2 control statement
   - ISO:     At planned intervals (typically annually)
              A.9.2.5 requirement

   ⚠ IMPACT: PCI-DSS is most restrictive and MANDATORY
   ✓ RESOLUTION: Implement quarterly (90-day) access reviews

   Implementation:
   - Set automated reviews every 90 days
   - This satisfies PCI-DSS mandatory requirement
   - Exceeds NIST, ISO, SOC2 requirements
   - Document as quarterly in all framework documentation

   Code Example:
   ```python
   # AWS Lambda triggered every 90 days
   review_schedule = "rate(90 days)"

🔴 CONFLICT #2: Log Retention Period Control Area: Logging and Monitoring Affected Controls: NIST AU-11, ISO A.12.4.1, SOC2 CC7.3, PCI 10.7

Requirements:

• SOC2: Retention based on risk assessment

(typically 1 year minimum)

• PCI-DSS: One year minimum, with at least 3 months

immediately available for analysis Requirement 10.7 MANDATORY

• NIST: Organization-defined period

(typically 90 days online, 1 year archived)

• ISO: As required by applicable regulations

and contractual requirements

⚠ IMPACT: PCI-DSS specific requirements for availability ✓ RESOLUTION: 1 year total, 3+ months online/searchable

Implementation:

• Online logs: 6 months (exceeds PCI 3-month minimum)
• Archived logs: 6 months (total = 1 year)
• Use cheaper storage for archived logs
• Satisfies all framework requirements

Cloud Implementation: AWS:

• CloudWatch Logs: 6 months retention
• S3 Glacier: 6 months archived (total 1 year)

Azure:

• Log Analytics: 6 months
• Archive Storage: 6 months

GCP:

• Cloud Logging: 6 months
• Cloud Storage Archive: 6 months

🔴 CONFLICT #3: Inactive Account Handling Control Area: Account Management Affected Controls: NIST AC-2(3), SOC2 CC6.1, PCI 8.1.4

Requirements:

• SOC2: Remove or disable inactive accounts based on

risk assessment (no specific timeline)

• PCI-DSS: Remove/disable inactive user accounts at least

every 90 days - Requirement 8.1.4 MANDATORY

• NIST: AC-2(3) - Organization-defined time period

(commonly 90 days for government)

• ISO: Review access rights at regular intervals

⚠ IMPACT: PCI-DSS mandatory 90-day requirement ✓ RESOLUTION: Automatically disable accounts after 90 days

Implementation:

• Automated detection of accounts inactive 90+ days
• Automatic disablement (not deletion)
• Exception process for service accounts
• Monthly review of disabled accounts

Automation:

   # Disable users inactive for 90+ days
   inactive_threshold_days = 90

   def disable_inactive_users():
       users = iam.list_users()
       for user in users:
           last_used = get_last_activity(user)
           if days_since(last_used) >= 90:
               iam.disable_user(user)
               notify_security_team(user)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MEDIUM SEVERITY CONFLICTS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🟡 CONFLICT #4: Vulnerability Scan Frequency Control Area: Vulnerability Management

Requirements:

• PCI-DSS: Quarterly external scans by ASV

Quarterly internal scans Scans after significant changes

• NIST: Organization-defined frequency (monthly common)
• SOC2: Risk-based frequency
• CIS: Monthly vulnerability scans (Control 7.5)

✓ RESOLUTION: Monthly internal, quarterly external by ASV

• Satisfies PCI quarterly minimum
• Satisfies CIS monthly recommendation
• Exceeds NIST and SOC2 expectations

🟡 CONFLICT #5: Fire