A basic set of processes should include the following high level categories:
Threat analysis - this should include all types of threats; natural disasters, terrorist attack, foreign espionage etc and should be reviewed annually to understand and prepare for likely incidents. These threats should be mapped to incidents and these mappings should feed into the development of incident response procedures. This is the key preparatory stage.
Classification of incidents - classification should be owned centrally, and should be the responsibility of the business. This classification should include impact and likelihood thresholds, along with escalation requirements. This will help determine how incidents are responded to, with what urgency, and with what sort of resolution expectations.
Operational procedures - communication and escalation procedures should be formalised and documented for each business unit. These need to include named individuals or teams, service levels, response times, and communication protocols within and outside the team and organisation. The teams involved will depend on classification of the incident, but each team will require operational procedures to meet standard requirements for communication, measurement, integrity and resilience.
Post incident review - post incident review should be formalised and mandatory for all incidents. This should include a complete impact assessment to help the organisation understand the incremental, long term and intangible costs of the incident.
Final closeout - closeout should include recording of incident resolution time and activities, as well as the comparison with the expected outcome so that improvement can be made.
I think, from the wording of the question, that you are most interested in the Operational Procedures section, so I'll drop down a level here:
Operational Procedures will include items like:
- Retention of all information recorded by the incident team from the beginning of the incident to at least the closeout. Beyond that time, retention will be according to corporate or regulatory requirements.
- Putting a hold on all log rotation - instead of following the normal log rotation cycle, logs dating back a defined amount (this may be an hour, a day or longer) will be made available to the investigation team.
- As any incident could be a criminal incident, no matter what it first looks like (As an example, tectonic exfiltration - opportunistic theft of hardware occurred during the chaos caused by the earthquakes in New Zealand) the recording of data should be as complete as possible, and recorded to storage that is Write-Once, Read-Many if possible, and forensic rules should apply.
- Identification of activities to rapidly remediate and get back to Business-as-Usual, as well as activities to fully investigate the root cause of the incident.
- Internal and External incidents may be dealt with very differently (for example an employee who has stolen critical data may just be fired and walked off the site, but evidence that a competitor has been carrying out industrial espionage may be passed to the police, or may be quietly hidden - these decisions will have business outcomes so need to be discussed at the level of the Chief Risk Officer or equivalent)
Remember that every item or activity is a cost option, so we very rarely see all of these carried out. The first to go is usually the forensic recording of data or activities, as a business suffering a major incident may be losing money every minute the incident continues. The driver is likely to be getting back up to normal operating procedures first, followed by an investigation after the fact.
For a couple of specifics on Computer Security Incident Response, check out this IETF document and this CERT document.