SteelCortex Documentation Centre
The Documentation Centre is the operational reference for organisations using, evaluating or implementing SteelCortex. It explains not only where functions are located, but how the platform and services are intended to be used responsibly and effectively.
Documentation should help a new user understand the platform, help an analyst follow a consistent workflow, help an administrator configure the environment correctly and help leadership understand how SteelCortex findings and reports should be interpreted.
1. Getting Started
Platform Orientation
Understand the SteelCortex operating model, main navigation, dashboard structure, security workflow and the relationship between Platform, Services, Solutions and Resources.
Initial Onboarding
Define organisation scope, key contacts, critical systems, business priorities, user roles, expected outputs and the security questions the engagement or deployment needs to answer.
Environment Setup
Prepare the assets, domains, cloud environments, identities, data sources and existing security tools that may need to be represented or integrated.
2. User Roles & Access
Access should follow least-privilege principles. Documentation should clearly explain what each role can view, edit, investigate, administer and report.
- Organisation Administrator: manages users, organisation settings, core integrations and access governance.
- Security Analyst: reviews alerts, vulnerabilities, evidence, investigations, timelines and response actions.
- IT / Remediation Owner: receives and manages technical remediation actions relevant to assigned systems.
- Executive / Read-only: views posture, material risk, incident status and management reporting without operational privileges.
- External Adviser / Service Provider: receives controlled access appropriate to a defined engagement or support role.
3. Core Platform Workflows
Monitoring Workflow
How security signals are reviewed, prioritised, contextualised, assigned and escalated without treating every alert as an incident.
Vulnerability Workflow
How findings are grouped, prioritised, assigned, remediated, validated and reported, with emphasis on risk rather than raw volume.
Attack Surface Workflow
How public-facing assets and exposures are discovered, validated, contextualised and reduced over time.
Investigation Workflow
How analysts collect evidence, create timelines, document hypotheses, determine scope, identify root cause and record conclusions.
Response Workflow
How containment, eradication, recovery, communications, ownership and follow-up actions are recorded and coordinated.
Reporting Workflow
How technical detail is converted into executive, operational and technical outputs appropriate to different audiences.
4. SOC Dashboard
The SOC Dashboard is the operating view for security activity. Documentation should explain every metric, status indicator and workflow control so users understand what the interface represents and what it does not represent.
- Security posture and risk summaries
- Incident and alert status
- Critical asset and vulnerability visibility
- Assigned actions and operational workload
- Recent changes, escalations and follow-up requirements
- Executive versus analyst views
5. Investigation Centre
The Investigation Centre should provide a structured case record rather than a loose collection of analyst notes. Documentation should cover evidence handling, chronology, affected entities, conclusions and the distinction between facts and analyst interpretation.
- Create and classify an investigation
- Record affected users, systems, assets and data
- Build a timeline of relevant events
- Attach or reference supporting evidence
- Document hypotheses and findings
- Record containment and remediation actions
- Close the investigation with an evidence-based conclusion
6. Vulnerability & Remediation Management
Documentation should explain how SteelCortex prioritises weaknesses and how teams can avoid the common mistake of treating every vulnerability as equally urgent.
- Severity versus business risk
- Asset criticality and exposure
- Known exploitation and practical attack paths
- Remediation ownership and target dates
- Exceptions, compensating controls and accepted risk
- Validation and closure
- Repeat findings and trend reporting
7. Attack Surface Management
This section should document how public-facing domains, websites, APIs, cloud endpoints, email infrastructure and exposed services are represented, reviewed and prioritised. It should also explain verification requirements so that discovered assets are not automatically assumed to belong to a customer without confirmation.
8. Integrations
Integration documentation should explain what data SteelCortex expects, what permissions are required, what is read-only versus write-capable, how credentials are protected and what happens when an integration fails.
Cloud & Identity
Guidance for cloud accounts, directories, access controls and identity-related security context.
Security & Log Sources
Guidance for importing or referencing logs, alerts, vulnerability outputs and other security telemetry.
Web, API & External Assets
Guidance for representing public-facing infrastructure and validating asset ownership.
Reporting & Workflow
Guidance for moving findings into reporting, ticketing or operational processes where integrations are supported.
9. Reporting Studio
Reports should clearly distinguish observation, analysis, risk, recommendation and management decision. Documentation should explain the purpose of each report type and how readers should interpret severity, confidence and priority.
- Executive cyber-security summary
- Vulnerability and remediation report
- Attack-surface exposure report
- Incident investigation report
- Risk register and action plan
- Compliance-support evidence pack
- Periodic security posture report
10. AI-Assisted Features & Human Oversight
Where SteelCortex uses AI-assisted analysis, the documentation should state what the system is doing, what inputs it is using, what uncertainty may exist and when human review is required. Generated summaries or recommendations must not be presented as verified facts unless supported by evidence.
- AI may assist with summarisation, correlation, prioritisation and drafting.
- Analysts remain responsible for validating material conclusions.
- High-impact response actions should require appropriate human authorisation.
- Simulated, example or demonstration data must be clearly identified as such.
11. Data Handling & Security
Production documentation should describe tenant separation, encryption, authentication, audit logging, backups, retention, access control and incident management. It should also identify which responsibilities sit with SteelCortex and which remain with the customer.
12. Administration & Configuration
- Organisation profile and environment settings
- User provisioning and role changes
- MFA and authentication configuration
- Notification and escalation preferences
- Integration configuration and health
- Report scheduling and recipient controls
- Data retention and administrative audit records
13. Service Documentation
Each SteelCortex service should have its own scope document explaining objectives, prerequisites, activities, limitations, deliverables, customer responsibilities and what happens after the engagement.
Threat Monitoring & Detection
Coverage, triage, escalation, evidence and expected communication.
Vulnerability Assessment
Scope, testing boundaries, prioritisation methodology and remediation reporting.
Attack Surface Review
Discovery scope, ownership verification, exposure assessment and reduction plan.
Incident Response & Investigation
Initial triage, evidence requirements, investigation process and response outputs.
Cloud & Data Security
Cloud scope, identity, permissions, configuration and data-protection review.
Risk & Compliance Support
Risk translation, evidence structure, governance outputs and limitations.
14. Support & Troubleshooting
The support section should help users resolve common problems without hiding serious issues behind generic troubleshooting steps. It should include integration health checks, access problems, report generation issues, notification troubleshooting and escalation routes.
15. Documentation Standards
- Every page should state its purpose and intended audience.
- Procedures should include prerequisites, steps, expected result and recovery path.
- Security-sensitive actions should include warnings and required permissions.
- Examples must be identified as examples rather than real customer data.
- Version changes that affect workflows should be recorded in release notes.
- Deprecated behaviour should be clearly labelled and removed from active guidance when no longer supported.
Documentation roadmap
Before production launch, this centre should evolve into searchable product documentation with screenshots, workflow diagrams, onboarding runbooks, integration guides, report examples, release notes and troubleshooting articles. The structure on this page provides the information architecture for that final knowledge base.