Risk management is a critical CTA competency. The review board evaluates whether you can proactively identify risks in a scenario, assess their probability and impact, and propose concrete mitigation strategies. Candidates who only address risks when prompted score lower than those who weave risk awareness throughout their architecture.
Risk Categories
Technical Risks
| Risk | Description | Likelihood | Impact |
|---|
| Governor limit exceedance | Automation or integration hits platform limits | Medium | High |
| Performance degradation | Slow queries, page load times with data growth | High | High |
| Integration failure | External system downtime, API changes | Medium | High |
| Data migration errors | Incomplete, duplicated, or corrupted data | Medium | High |
| Security vulnerability | FLS bypass, sharing model gaps, injection | Low | Critical |
| Technical debt accumulation | Shortcuts that compound over time | High | Medium |
| Platform upgrade impact | Salesforce releases breaking existing functionality | Low | Medium |
Organizational Risks
| Risk | Description | Likelihood | Impact |
|---|
| Key person dependency | Single expert with no backup | Medium | High |
| Stakeholder misalignment | Business units with conflicting requirements | Medium | High |
| Change resistance | Users refusing to adopt new system | Medium | High |
| Scope creep | Requirements expanding beyond original scope | High | Medium |
| Resource availability | Team members pulled to other projects | Medium | Medium |
| Vendor dependency | AppExchange vendor acquired or sunset | Low | High |
| Knowledge gaps | Team lacks skills for chosen technology | Medium | Medium |
Data Risks
| Risk | Description | Likelihood | Impact |
|---|
| Data quality issues | Dirty data causing automation failures | High | Medium |
| Data volume growth | Unexpected data growth exceeding storage | Medium | High |
| Data loss | Accidental deletion, failed migration | Low | Critical |
| PII exposure | Sensitive data visible to unauthorized users | Low | Critical |
| Data silos | Duplicate data across systems with no sync | Medium | Medium |
Integration Risks
| Risk | Description | Likelihood | Impact |
|---|
| API version deprecation | External system deprecates API version | Medium | High |
| Message ordering | Events processed out of order | Medium | Medium |
| Data inconsistency | Sync failures creating divergent data | Medium | High |
| Rate limiting | External system throttles API calls | Medium | Medium |
| Authentication expiry | Tokens, certificates, or credentials expire | Medium | High |
Probability x Impact Matrix
Use this matrix to prioritize risks and determine which require active mitigation vs monitoring.
quadrantChart
title Risk Assessment Matrix
x-axis Low Impact --> High Impact
y-axis Low Probability --> High Probability
quadrant-1 Mitigate Actively
quadrant-2 Monitor Closely
quadrant-3 Accept and Monitor
quadrant-4 Contingency Plan
Governor Limits: [0.75, 0.50]
Performance: [0.80, 0.70]
Integration Failure: [0.75, 0.45]
Data Migration: [0.70, 0.50]
Security Vulnerability: [0.90, 0.25]
Key Person Dependency: [0.65, 0.55]
Scope Creep: [0.55, 0.75]
Change Resistance: [0.60, 0.55]
Data Quality: [0.50, 0.70]
Vendor Dependency: [0.70, 0.20]
Response Strategies by Quadrant
| Quadrant | Strategy | Action |
|---|
| High Probability, High Impact | Mitigate Actively | Invest in prevention. Design architecture to avoid this risk. Budget time and resources. |
| Low Probability, High Impact | Contingency Plan | Have a documented response plan. Do not invest in prevention, but be prepared to respond. |
| High Probability, Low Impact | Monitor Closely | Accept the risk but track it. Set thresholds for escalation. |
| Low Probability, Low Impact | Accept and Monitor | Log the risk but do not invest resources. Review periodically. |
Risk Response Flow
When a risk is identified, it must be assessed, classified, and assigned a response strategy. This flow ensures consistent handling across the project.
flowchart TD
A([Risk Identified]) --> B[Log in Risk Register]
B --> C[Assess Probability<br/>& Impact]
C --> D{Risk Score?}
D -->|Critical<br/>P x I >= 9| E[Mitigate Actively<br/>Design architecture<br/>to prevent]
D -->|High<br/>P x I >= 6| F[Contingency Plan<br/>Document response<br/>procedures]
D -->|Medium<br/>P x I >= 3| G[Monitor Closely<br/>Set alert thresholds<br/>Review each sprint]
D -->|Low<br/>P x I < 3| H[Accept & Log<br/>Review quarterly]
E --> I[Assign Owner<br/>Set Review Date]
F --> I
G --> I
H --> I
I --> J{Risk Status<br/>Check}
J -->|Materialized| K[Execute Contingency<br/>Escalate to CAB]
J -->|Probability Changed| C
J -->|Resolved| L[Close Risk<br/>Document Lessons Learned]
J -->|Unchanged| M[Continue Monitoring]
M --> J
style A fill:#4ecdc4,stroke:#3ab5ad,color:#000
style E fill:#e76f51,stroke:#c45a3f,color:#fff
style F fill:#f4a261,stroke:#d4823e,color:#000
style K fill:#e76f51,stroke:#c45a3f,color:#fff
style L fill:#2d6a4f,stroke:#1b4332,color:#fff
Risk Register Template
A risk register is the operational tool for tracking risks throughout the project. In a CTA scenario, reference the risk register as part of your governance approach.
| Field | Description | Example |
|---|
| Risk ID | Unique identifier | RISK-001 |
| Category | Technical, Organizational, Data, Integration | Technical |
| Description | What could go wrong | ”SOQL queries on Account may degrade with 10M+ records” |
| Probability | High, Medium, Low | High |
| Impact | Critical, High, Medium, Low | High |
| Risk Score | Probability x Impact (numeric) | 9 (3 x 3) |
| Mitigation Strategy | What you will do to reduce probability or impact | ”Implement skinny tables, selective indexes, archive records >5 years” |
| Contingency Plan | What you will do if the risk materializes | ”Implement async processing, increase timeout, add caching layer” |
| Owner | Who is responsible for monitoring this risk | Technical Architect |
| Status | Open, Mitigating, Closed, Materialized | Mitigating |
| Review Date | When to next review this risk | Every sprint retrospective |
Common CTA Scenario Risks and Mitigations
Scenario: Large Data Volume Implementation
| Risk | Mitigation | Contingency |
|---|
| Query performance degradation | Skinny tables, custom indexes, selective filters | Implement caching, async processing |
| Storage limit exceedance | Data archival strategy, Big Objects | Purchase additional storage, aggressive archival |
| Data migration timeout | Batch processing, parallel loads, off-hours | Phased migration over multiple weekends |
| Report performance | Summary reporting objects, async reports | CRM Analytics for complex reporting |
Scenario: Multi-Cloud Implementation
| Risk | Mitigation | Contingency |
|---|
| Cross-cloud data inconsistency | Event-driven sync, conflict resolution rules | Manual reconciliation process, data steward role |
| License cost overrun | License optimization analysis, feature mapping | Renegotiate license mix, consolidate users |
| Integration complexity | Middleware layer, standardized patterns | Simplify to point-to-point for critical paths |
| User adoption challenges | Role-specific training, change champions | Phased rollout, parallel running |
Scenario: AppExchange-Heavy Architecture
| Risk | Mitigation | Contingency |
|---|
| Vendor acquisition/sunset | Exit strategy for each package, data portability | Build replacement with custom code |
| Governor limit conflicts | Limit budget allocation per package, monitoring | Remove lowest-value package, optimize custom code |
| Upgrade breaking changes | Regression test suite, staging validation | Version lock, coordinate with vendor |
| Total cost escalation | TCO model with annual review triggers | Renegotiate or replace with custom build |
Scenario: Global/Multi-Org Rollout
| Risk | Mitigation | Contingency |
|---|
| Regulatory non-compliance | Per-region compliance mapping, Shield encryption | Region-specific org isolation |
| Data residency violation | Hyperforce region selection, data masking | Separate orgs per jurisdiction |
| Timezone/language issues | Locale-aware development, i18n testing | Region-specific customization layer |
| Coordinated deployment complexity | Release train model, feature flags | Staggered regional releases |
Risk Communication
How to Present Risks to the Review Board
The CTA review board expects you to present risks as a structured, proactive analysis — not as an afterthought.
Structure your risk discussion as:
- Identify the top 3-5 risks specific to the scenario (not generic risks)
- For each risk, state:
- What the risk is and why it exists in this specific scenario
- How likely it is and how severe the impact would be
- What you are doing architecturally to prevent it
- What the fallback plan is if prevention fails
- Connect risks to architecture decisions: “I chose middleware over point-to-point integration partly because it reduces the integration failure risk by providing retry logic and monitoring.”
CTA Risk Presentation Pattern
“The top risk I see in this scenario is [risk]. It’s likely because [reason specific to scenario]. If it materializes, the impact is [consequence]. My architecture mitigates this by [architectural decision]. As a contingency, [fallback plan].”
Risk Reporting
| Audience | Detail Level | Format | Frequency |
|---|
| Steering Committee | High-level, top 5 risks | Dashboard, RAG status | Monthly |
| Project Team | Detailed, all active risks | Risk register | Sprint review |
| Technical Team | Technical risks with actions | Technical risk log | Weekly standup |
| CAB | Deployment-specific risks | Change request form | Per deployment |
Risk Monitoring
Early Warning Indicators
| Risk Area | What to Monitor | Alert Threshold |
|---|
| Governor limits | Apex CPU time, SOQL count per transaction | >70% of limit |
| Performance | Page load time, query execution time | >3 second page load |
| Storage | Data storage usage, file storage usage | >80% capacity |
| Integration | Error rate, response time, queue depth | >5% error rate |
| API limits | Daily API call consumption | >70% of daily limit |
| User adoption | Login frequency, feature usage | <50% expected adoption |
Sources