Investigate the incident before choosing the fix
An application stops working after a change. The service desk has user reports, an engineer has a dashboard, and the person who understands the original design is unavailable. The immediate task is to establish what failed, who is affected and which evidence supports the next action.
This guide gives Microsoft-focused IT teams a repeatable investigation checklist and explains where a governed AI agent can assist. The method also applies when the affected system includes networks, servers or applications outside Microsoft.
An IT incident investigation checklist
1. Define the impact and time window
Record the affected service, first known failure, last known success, user groups, locations and devices. Keep one incident record with an owner and a consistent time zone. Include a working comparison, such as an unaffected user or device, so the team can distinguish a broad outage from a narrower access or configuration problem.
2. Preserve the evidence
Collect relevant logs, configuration snapshots, alerts, tickets and recent change records before retention limits or further changes remove context. Record the source and collection time. Limit access to people who need it and avoid copying credentials or unnecessary personal information into incident notes.
3. Build a timeline and test explanations
Place reported symptoms, deployments and policy changes on the same timeline. A change occurring before an incident is a lead to investigate; timing alone does not establish the cause. Check whether the change actually applies to the affected users or systems, and whether the same explanation fits an unaffected comparison.
4. Agree a controlled recovery action
Document the proposed action, expected impact, approver, verification steps and recovery plan if the action fails. Use the smallest practical scope. An AI-generated explanation should remain a hypothesis until the evidence and responsible operator support it.
5. Verify recovery and keep the learning
Confirm that the affected workflow works again and check for unintended effects. Update the incident with the evidence, actions, outcome and remaining uncertainty. Link the record to the relevant configuration, runbook and service owner so the next investigation starts with useful context.
Worked example: users cannot access an application
This is an illustrative scenario, not a customer result. Several users report sign-in failures after a Conditional Access change. Avoid assuming that every blocked sign-in is an MFA failure: a device compliance requirement can also prevent access.
In Microsoft Entra sign-in logs, find a matching event using the user, time, resource or correlation ID. Review its Conditional Access tab to identify the policies involved, then inspect the device and authentication details. Error 53000 indicates DeviceNotCompliant; 53003 indicates BlockedByConditionalAccess. These details help separate policy enforcement from an authentication problem.
For the supported diagnostic workflow, see Microsoft: troubleshoot sign-in problems with Conditional Access
Compare the affected event with a successful sign-in and the approved change record. If the policy scope explains the difference, document the finding and agree a scoped correction. If it does not, keep investigating rather than disabling a broad security control to test a guess.
Where Operational Intelligence and an IT AI agent fit
Veles IT Solutions provides Operational Intelligence as an enterprise AI implementation service. We work with your team to connect the knowledge, actual configuration, dependencies, telemetry, tickets and historical changes needed for a defined operational use case.
For incident investigation, the intended workflow is to ask questions such as "What changed?", "Who is affected?" and "What would this change break?" and receive an explanation tied to accessible evidence. The sources an agent can use, the context it can retain and the actions it can recommend depend on the agreed implementation and permissions.
A useful result should distinguish observations from hypotheses, identify missing evidence and show where the explanation came from. Recommendations and any authorized automation need least privilege, audit, verification and recovery. The IT team retains responsibility for approving changes.
Explore Veles Operational Intelligence services
Start with one investigation your team repeats
Choose an incident type where engineers repeatedly gather the same evidence or depend on a particular person for context. Review the data sources, access boundaries and current investigation steps. Agree how you will evaluate evidence quality, time spent gathering information and whether the result helps an operator make a sound decision.
Bring that example to a free initial conversation with Veles. We will discuss your current process and whether an Operational Intelligence engagement is a useful next step. Scope and pricing are agreed before paid work begins.
