IT management produces decisions with significant operational, security, and financial consequences: technology selections that commit the organization to platforms for years, security risk decisions that determine what vulnerabilities to accept and which to remediate immediately, vendor negotiations that establish the terms of relationships affecting critical infrastructure, and architectural changes that affect every user in the organization. Each of these decisions requires research, and each benefits from a structured research-to-output workflow that makes the reasoning transparent and creates an auditable record.
The research-to-output workflow for IT managers links intelligence gathering to decisions through structured analysis — because in IT management, the decision record matters long after the decision is made.
Stage 1: Incident Post-Mortem Research
Every significant incident — a major outage, a security breach, a data loss event — warrants a post-mortem that produces documented learnings rather than just resuming operations after resolution.
The incident post-mortem structure:
INCIDENT POST-MORTEM REPORT
Incident ID: [ID]
Incident: [Brief description]
Date: [Occurrence date]
Duration: [Total duration from detection to resolution]
TIMELINE:
[Time]: [What happened or what action was taken]
[Time]: [...]
[Continue chronologically]
IMPACT:
Systems affected: [Which systems and services]
Users affected: [Approximate number + which groups]
Business impact: [What business processes were disrupted + how long]
Data impact: [Any data loss or data exposure]
Financial impact: [If quantifiable — revenue lost, SLA penalties, remediation cost]
ROOT CAUSE:
Immediate cause: [The directly observable technical cause]
Contributing causes: [Other factors that allowed the immediate cause to have the impact it did]
Root cause: [The systemic cause — what in the management system, process, or architecture allowed this to happen]
Root cause category: [Infrastructure / Configuration / Software / Capacity / Security / Process / External]
DETECTION:
How it was detected: [Alert / User report / Monitoring / Discovered by IT team]
Time to detection from occurrence: [How long before the problem was known]
How it could have been detected earlier: [What monitoring, alerting, or process would have surfaced it faster]
DIAGNOSIS:
Time from detection to root cause identification: [Duration]
Diagnosis path: [How root cause was identified]
Dead ends in diagnosis: [What was investigated but turned out not to be the cause — and why it was misleading]
What would have found it faster: [What should be checked first if these symptoms appear again]
RESOLUTION:
How resolved: [What was done]
Time from diagnosis to resolution: [Duration]
Rollback was considered: [ ] Yes [ ] No — [If yes: why rollback was or wasn't used]
CONTRIBUTING FACTORS:
Process gaps: [Any process failures that contributed — missing runbook, change management process not followed]
Monitoring gaps: [Any monitoring that should have caught this earlier]
Documentation gaps: [Any CMDB or system documentation that was inaccurate or missing]
Communication gaps: [Any communication failures during the incident]
CORRECTIVE ACTIONS:
Action 1: [What + responsible party + deadline]
Action 2: [...]
Monitoring improvements: [What new or modified alerts will catch this earlier]
Documentation updates: [What CMDB or runbook changes are needed]
Process improvements: [What process changes will prevent or reduce impact]
LESSONS LEARNED:
What this incident taught us: [Non-obvious insights from this incident]
What we'll check first if this symptom appears again: [The fast diagnosis path]
What we'd do differently in the response: [Response process improvements]
KB updates: [ ] Infrastructure KB [ ] Incident KB [ ] Runbook [ ] Security KB
The timeline as the root cause tool: the incident timeline, recorded accurately, often reveals the root cause without additional analysis. The change that was made 2 hours before the incident started, the component that began degrading 6 hours before the full failure, the configuration change that was deployed to one server but not the other — these appear in the timeline.
Stage 2: Technology Evaluation and Selection
Technology evaluations — selecting a new tool, platform, or vendor — require structured research that documents the evaluation criteria, the alternatives considered, and the basis for the recommendation.
The technology evaluation structure:
TECHNOLOGY EVALUATION — [Technology Category, Date]
EVALUATION OBJECTIVE:
What we're evaluating: [Technology category or specific solution type]
Business driver: [What problem this is intended to solve]
Success criteria: [What a successful implementation looks like]
REQUIREMENTS:
Must-have requirements:
[ ] [Requirement 1]
[ ] [Requirement 2]
Important requirements:
[ ] [Requirement A]
[ ] [Requirement B]
Nice-to-have:
[ ] [Requirement X]
MARKET RESEARCH:
Solutions in this category: [What the available options are]
Market leaders: [What analyst research, community reputation, or peer recommendations indicate]
Solutions eliminated from consideration: [What was excluded and why]
Source: [How market research was conducted — analyst reports, peer recommendations, RFP responses]
Date of research: [Date — technology categories change quickly]
SOLUTIONS EVALUATED:
[Solution 1]:
Meets must-have requirements: [Yes / No / Partially]
Important requirement assessment: [How it performs on important requirements]
Strengths: [What it does well]
Weaknesses: [What it doesn't do well or is missing]
Pricing: [Licensing model + estimated annual cost]
Integration complexity: [How complex to integrate with our environment]
Vendor assessment: [Vendor stability, support quality, roadmap]
Reference check: [What references or peer users report]
[Solution 2]: [Same structure]
[Solution 3]: [...]
SECURITY ASSESSMENT:
For each solution under consideration:
Security architecture: [How the solution handles authentication, authorization, data protection]
Compliance certifications: [SOC 2 / ISO 27001 / FedRAMP / relevant certifications held]
Data handling: [Where data is stored + how it's handled + DPA/privacy terms]
Penetration testing: [When last tested + results if available]
Incident history: [Any known security incidents with this vendor]
PROOF OF CONCEPT (if conducted):
What was tested: [Scope of PoC]
Test environment: [How the PoC was run]
Results: [What was found + any issues discovered]
PoC conclusion: [Did the PoC confirm the solution meets requirements?]
RECOMMENDATION:
Recommended solution: [Which one + why]
Alternatives considered and why not recommended: [Brief for each]
Implementation approach: [High-level implementation plan]
Total cost of ownership: [Year 1 + Year 3 projections]
Key risks: [What could go wrong + mitigations]
Decision: [Decision made + by whom + date]
The security assessment for every technology evaluation: cloud SaaS tools, third-party software, and new infrastructure components all carry security implications. The security assessment — compliance certifications, data handling, recent security incidents — is not a separate step after the technology decision; it's built into the evaluation.
Stage 3: Security Risk Assessment
Security risk assessments — for new projects, for known vulnerabilities, for compliance audits — require structured research that produces a documented risk record.
Security risk assessment structure:
SECURITY RISK ASSESSMENT — [System or Project, Date]
SCOPE:
What's being assessed: [System, project, or change in scope]
Assessment trigger: [New project / Vulnerability identified / Compliance requirement / Periodic review]
ASSETS IN SCOPE:
Data: [What data is handled + classification + volume]
Systems: [What systems are in scope]
Processes: [What processes handle or depend on this data/system]
THREAT ANALYSIS:
Threat 1: [Threat actor/scenario + likelihood + if exploited, impact]
Threat 2: [...]
VULNERABILITY ASSESSMENT:
[Vulnerability 1]:
CVSS score: [If CVE]
Exploitability: [How easy to exploit in our environment]
Exposure: [Who can reach this vulnerability]
Compensating controls: [What's in place that reduces risk]
[Vulnerability 2]: [...]
RISK RATING:
Likelihood: [High / Medium / Low — with rationale]
Impact: [High / Medium / Low — with rationale]
Overall risk: [Critical / High / Medium / Low]
RISK TREATMENT:
[ ] Remediate: [What specific remediation + timeline]
[ ] Mitigate: [What compensating control + how it reduces risk]
[ ] Transfer: [How risk is transferred — insurance, contract term]
[ ] Accept: [Rationale for acceptance + who approved]
RESIDUAL RISK:
Risk level after treatment: [Risk rating after mitigations applied]
Risk acceptance documentation: [If accepted — date + who approved + rationale]
REMEDIATION TRACKING:
Action: [What + who + deadline]
Verification: [How we'll confirm remediation is effective]
SOURCES:
CVE records: [NVD URLs + archive.org backups + dates captured]
Vendor advisories: [URLs + archive.org backups + dates]
Threat intelligence: [Sources consulted]
Stage 4: Vendor Negotiation Preparation
Contract negotiations and vendor negotiations require structured preparation that draws on vendor intelligence, market research, and total cost analysis.
Worked example: Cloud platform contract renewal
An IT manager is preparing for an annual cloud infrastructure contract renewal. The current contract is approaching expiration with 120 days remaining.
Research conducted:
- Current contract review: current pricing, committed usage levels, discount tiers, exit provisions
- Cloud cost analysis: actual usage vs. committed vs. optimal — are we over- or under-committed?
- Market research: what are competitive cloud providers offering for equivalent workloads? What are current negotiating norms (RI/Savings Plan discount ranges)?
- Total cost model: projected usage growth for the next 12/24/36 months + cost at current pricing vs. alternatives
- Vendor relationship assessment: what value does this relationship provide beyond price? What migration complexity exists?
Output produced:
- Negotiation preparation document: current state + target state + leverage points + walk-away position + alternatives if negotiation fails
- Decision: negotiating targets established, approved by IT leadership before renewal negotiation begins
Stage 5: Compliance Gap Analysis
Compliance gap analyses — for new regulatory requirements, new certification programs, or periodic compliance reviews — require structured research that maps requirements to current controls and identifies gaps.
COMPLIANCE GAP ANALYSIS — [Framework/Regulation, Date]
FRAMEWORK: [e.g., "SOC 2 Type II" or "PCI-DSS v4.0"]
SCOPE: [What systems, data, processes are in scope]
ASSESSMENT DATE: [Date of analysis]
CONTROL DOMAIN ASSESSMENT:
Domain 1 — [e.g., "Access Control"]:
Requirement: [What the framework requires]
Current state: [What we currently have in place]
Gap: [ ] Fully compliant [ ] Partial gap [ ] Full gap
If gap: [Specific gap description]
Remediation: [What needs to be done + owner + timeline]
Evidence when compliant: [What documentation will demonstrate compliance]
Domain 2 — [...]
GAP SUMMARY:
Total requirements assessed: [Count]
Fully compliant: [Count + %]
Partial gaps: [Count + what they are]
Full gaps: [Count + what they are]
RISK PRIORITY:
Highest-risk gaps: [Which gaps pose the most risk if left unremediated]
REMEDIATION ROADMAP:
Phase 1 (0-30 days): [Highest priority gaps]
Phase 2 (30-90 days): [Medium priority gaps]
Phase 3 (90-180 days): [Lower priority gaps]
SOURCES:
Framework text: [Official standard reference + version]
Interpretive guidance: [Any official guidance on application of specific requirements]
Date of sources: [When these were accessed — frameworks are versioned and updated]
Key Takeaways
-
The research-to-output workflow for IT managers covers five major cycles. Incident post-mortems (timeline as root cause tool + what would have found it faster + corrective actions); technology evaluations (requirements → market research → solution comparison → security assessment → recommendation); security risk assessments (threat analysis + vulnerability assessment + risk treatment decision); vendor negotiation preparation (usage analysis + market research + total cost model + leverage assessment); compliance gap analysis (control mapping + gap identification + remediation roadmap).
-
The incident timeline is the most efficient root cause tool. A complete, accurate timeline of what happened when — including changes made, performance degradations, and alerts received in the hours before the incident — often reveals the root cause without additional analysis. The discipline of reconstructing the complete timeline should be the first step in any post-mortem.
-
Security assessment is built into every technology evaluation. Evaluating a technology without assessing its security posture means the security risk is invisible during the selection process and becomes a problem after deployment. Compliance certifications, data handling, and incident history are evaluation criteria, not afterthoughts.
-
Compliance gap analysis documentation creates the audit-readiness record. When an auditor asks "show me your access control implementation," the compliance gap analysis with its evidence references is the answer. The organization that documented its compliance posture before the audit performs the audit in hours; the one that reconstructs it under audit pressure takes days.
-
All technology evaluation research is dated. Technology categories, pricing, and competitive landscapes change rapidly. A technology evaluation from 18 months ago may not reflect the current market. Dating the research establishes when the evaluation was current and flags when a re-evaluation may be warranted.
Conclusion
The research-to-output workflow for IT managers connects intelligence to decisions through structured analysis: incident post-mortems that capture the timeline and lessons rather than just closing tickets; technology evaluations that document the requirements, alternatives, and security assessments behind recommendations; security risk assessments that produce auditable risk treatment records; vendor negotiations prepared with usage data and market research; and compliance gap analyses that map requirements to controls and create the audit-readiness record. The documentation of research behind each decision creates the institutional learning record that makes future incidents faster to diagnose, future evaluations more efficient, and future audits less traumatic.
See also: Best Web Clipper Extensions.