Assuming that this is your complete process, not a subset where other decisions have already been made, I would suggest that your first decision point is not whether or not there is an intrusion but whether or not there is a business service impact.
Alert -> Check Logs -> Business Service Impact?
After you've determined the business service impact you can use that to drive the rest of the incident response. If your service is impacted you need to engage the correct people in the business (which should already be documented) to notify them of the impact, providing an early overview of the problem.
Business Service Impact? -> Yes -> Notify Business Incident Manager
Once the business has been notified you can move on to determining the exact nature of the problem and working through the rest of your process flow.
If there is no business service impact you still move on to problem determination.
Business Service Impact -> No -> Intrusion?
My next point would be that, even if the event is not an Intrusion it may still be a security event which you wish (or need) to perform actions as a result of.
For example, you detect some form of automated or manual scan of your web applications. You may decide that you wish to block the attacker's IP address. This is just one simple example.
Such a decision may require authorisation from appropriate business or technology representatives so again, the necessary hooks in to the business must be reflected in your process flow.
In summary then, my feedback points are:
Don't forget you're defending a business application, ensure your incident response process reflects the needs of the business, not just detailing the technical steps required.
An intrusion is obviously worst case but don't discount actions required for other security related events. It may not just be mis-configuration.