Impact Analysis Template

What is impact analysis?

Impact analysis asks:

If we change this, what else could move?

Not only:

Which screen changes?

But also:

• Which process changes?
• Which systems and integrations are involved?
• Does any data change?
• Who works differently?
• Are controls being added or bypassed?
• Who consumes the result downstream?
• What could fail?
• What needs testing, monitoring or communication?

A good impact analysis turns:

“This looks simple.”

into:

“Here’s what we checked before calling it simple.”

Start with the change

Before tracing the impact, write down four things:

1. 1. What happens today?
2. 2. What should happen after the change?
3. 3. Why is the change needed?
4. 4. What is explicitly out of scope?

For the refund example:

That word—eligible—already gives us questions.

Which orders qualify? What does “before dispatch” mean? What if the courier status is delayed? Does “instant” mean initiated instantly or credited instantly?

Impact analysis often begins by discovering that one sentence isn’t as settled as it sounds.

Now trace it across ten areas.

The 10-Area Impact Check

Understand the process before the systems.

This could change:

• refund eligibility
• manual refund queues
• customer-support handling
• seller settlements
• finance reconciliation

Now manager approvals, IT support and security controls may work differently.

The requirement didn’t just change a system. It changed a process.

Ask:

Who does something differently after this change?

For each group, check whether its work, permissions, training or communication must change.

Secondary users are easy to miss. Until they meet the change in production.

Ask which applications participate in the journey—not only which application owns the screen.

The refund path might be:

Notifications, reporting and support tools may also consume the result.

For every integration, ask:

• Does the request or response change?
• Is a new field mandatory?
• Are existing consumers affected?
• What happens on timeout?
• Can the request be retried safely?
• Is the change backward-compatible?

The requirement may never mention an API. The change can still depend on one.

Changes often create data requirements nobody mentioned.

Ask:

• Do we need a new field?
• Does an existing field change meaning?
• Who creates and owns the data?
• Who consumes it?
• What happens when it is late, missing or wrong?

Automatic onboarding may depend on:

The requirement says:

“Create access automatically.”

The real question is:

What trustworthy data tells us which access to create?

Ask:

• Is an approval changing?
• Could a control be bypassed?
• Are permissions involved?
• Is sensitive data exposed?
• Is an audit trail required?
• Do regulatory or retention rules apply?

Imagine onboarding employees in Mumbai, London and New York.

Location, employment type and role may change which systems and data they can access. A contractor should not receive privileged access simply because a job title was entered incorrectly.

You might need rules such as:

• Standard access follows the employee's approved role.
• Privileged access always requires separate approval.
• Contractors receive time-bound access.
• Access cannot begin before the joining date.
• Access is cancelled if the employee does not join.

Automation doesn’t remove controls. It changes where they happen.

One of the best BA questions is:

Who consumes this after us?

For the refund change:

• Finance may receive refunds earlier.
• Support may see new statuses.
• Reporting may calculate turnaround time differently.
• Fraud may require new alerts.
• Sellers may see settlement adjustments sooner.

Suppose Finance tracks:

An instant refund may shorten or remove one state. Dashboards, SLA calculations and reconciliation rules could then change too.

Your system can work perfectly and still break someone else’s process.

Don’t stop at:

“Our part works.”

Follow the output one step further.

Happy paths are easy. Failures are where impact analysis earns its keep.

For the refund change, what happens if:

• the order is cancelled but the refund fails?
• the refund succeeds but the notification fails?
• the payment gateway times out?
• the system retries the same request?
• one part succeeds and another does not?

Could the customer receive two refunds?

For onboarding, what if access is created but the employee’s joining date is later changed—or the employee never joins?

These aren’t only technical questions. They define business behaviour.

New behaviour raises an easy-to-miss question:

What happens to things already in progress?

For example:

• Do existing refund requests use the new flow?
• Should pending refunds be reprocessed?
• Do current employees need their access recalculated?
• Does a new field need to be populated for old records?
• Can old and new versions coexist during rollout?

Sometimes the feature is simple. Moving safely from the old world to the new one isn’t.

“It works” is different from “it works under real load.”

Ask:

• How many requests could arrive at once?
• Is there a response-time expectation?
• Are there payment-provider or API rate limits?
• Could automation create a large queue on joining day?
• What monitoring or alerting is needed?
• Who handles exceptions?

A refund flow that works for ten requests may behave very differently during a festival sale.

An onboarding flow may face hundreds of new joiners after an acquisition.

Volume is part of the requirement—even when Jira forgets to mention it.

Impact analysis gives QA the map. Testing explores the map.

For onboarding, scenarios might include:

• employee joins today
• employee joins next week
• joining date changes
• employee record is cancelled
• job role or manager is missing
• department changes before joining
• provisioning partly fails
• privileged access requires approval
• the same event is received twice

Also decide:

• What requires regression testing?
• Do we need integration, security or performance testing?
• Can the change be released gradually?
• How will we know it is working?
• What is the rollback plan?
• Who supports it after release?

Release is not the last line of the ticket. It is part of the change.

Copy-Paste Impact Analysis Template

## Change summary

[Describe the change in one sentence.]

## Business reason

[Why is the change needed?]

## Current behaviour

[What happens today?]

## Expected behaviour

[What should happen after the change?]

## Scope

- In scope:
- Out of scope:

## 1. Business process impact

- Current process:
- New process:
- Steps added, changed or removed:

## 2. User and team impact

- Primary users:
- Secondary users:
- Teams affected:
- Workflow, training or communication changes:

## 3. System and integration impact

- Systems / integrations touched:
- Request or response changes:
- Error handling:
- Retry behaviour:
- Existing consumers affected:

## 4. Data impact

- Data elements (current / new / source / consumer):
- Data ownership:
- Validation:
- Missing or incorrect data behaviour:

## 5. Rules, controls and security

- Existing rule or control:
- New rule or control:
- Approval impact:
- Permissions or privacy impact:
- Audit or regulatory impact:

## 6. Downstream, reporting and reconciliation

- Downstream system or team:
- Reports or dashboards:
- Reconciliation or SLA changes:
- Action required:

## 7. Failure and recovery

- Source unavailable:
- Timeout:
- Partial success:
- Duplicate request:
- Recovery or manual handling:

## 8. Historical data and migration

- Existing in-flight items:
- Historical-data update:
- Backfill or migration:
- Compatibility considerations:

## 9. Performance and operations

- Expected volume:
- Response-time expectation:
- Operational limits:
- Monitoring and alerts:
- Support owner:

## 10. Testing, release and rollback

- New scenarios:
- Regression areas:
- Integration / security / performance testing:
- UAT:
- Release approach:
- Rollback plan:

## Dependencies

-

## Assumptions

-

## Open questions

- Question:
- Owner:
- Due date:

## Decisions

- Decision:
- Decision owner:
- Reason:
- Date: