Risk & Compliance
Govern Technology Risk Where the Work Happens
Record risks, exceptions, policies and audit evidence alongside the services and changes they relate to.
Risk & Compliance provides Nexus-native risk and compliance capabilities for technology operations. It complements, and does not replace, the broader iShield GRC offering from iShield GRC Ltd.
- Obligation
- Risk
- Control
- Evidence
- Test
- Audit
The enterprise challenge
Compliance is a separate project from operations
Evidence is gathered before each audit, and exceptions approved in email are forgotten.
Technology compliance becomes sustainable when evidence is a by-product of operations rather than a project before each audit. Risk & Compliance maps obligations to controls, and controls to the change, incident, access and supplier records that already exist in Nexus — so control testing draws on what actually happened, exceptions carry owners and expiry dates, and an auditor's request is answered from the record. It provides Nexus-native risk and compliance for technology operations and complements, rather than replaces, the enterprise-wide iShieldGRC offering from iShield GRC Ltd.
Evidence scramble
Audits trigger weeks of collection.
Forgotten exceptions
Waivers outlive their purpose.
Disconnected risk
Risks aren't linked to services.
Signature view
The Control Mapping Lattice
Technology risk and compliance are managed within operational workflows, with evidence ready for audit.
The Control Mapping Lattice: obligations on the left, controls in the middle and the operational records that evidence them on the right, with test results flowing back to each control. Select a control to trace what it satisfies and what proves it. Conceptual illustration, not a product screen.
Incident response — Security and service incidents are handled to a defined process. Satisfies: information security policy; data-protection obligation; operational resilience requirement.
- Control record
- Control record, linked playbooks, test results
- Who decides
- Control owner
- Evidence drawn from
- Incident and security incident records with timelines
What Risk & Compliance covers
Approved baseline capabilities and the detail restored from the historical module record, labelled by provenance.
Approved baseline
- Approved baseline
Risk
Identify and track risk.
- Risk register
- GRC risk suite
- Approved baseline
Policy & exceptions
Set and manage rules.
- Policies
- Exceptions
- Approved baseline
Compliance & audit
Prove control.
- Compliance and audit
- Audit logs
- Governance hardening
- Approved baseline
Privacy & regulation
Meet obligations.
- Privacy assessments
- Regulatory templates
Restored from the historical record
- Restored · historical record
IT Risk Assessment & Registry
Identify, assess and track IT risks systematically.
- Risk identification across IT operations
- Qualitative and quantitative risk scoring
- Risk appetite and tolerance definition
- Risk treatment plans and tracking
- Risk heat maps and trend analysis
- Restored · historical record
Control Framework Management
Map and manage controls across frameworks.
- Control library structured around frameworks such as ISO/IEC 27001, NIST and COBIT
- Control effectiveness testing
- Evidence collection and management
- Control-to-risk-to-obligation mapping
- Gap analysis and remediation tracking
- Restored · historical record
Compliance Monitoring & Reporting
Maintain continuous compliance visibility.
- Compliance dashboards drawn from current records
- Automated compliance assessments
- Regulatory change impact analysis
- Policy lifecycle management
- Board-level compliance reporting
- Restored · historical record
Audit Management
Streamline internal and external audit processes.
- Audit planning and scheduling
- Finding and observation tracking
- Corrective action management
- Evidence request workflows
- Audit trail and documentation
Detail reconciled from the approved historical Nexus module record (additive restoration; legacy performance figures excluded per the claims policy).
From identified risk to audit evidence
Trigger: A risk is identified in operations or a review.
Identify
Risk recorded.
Assess
Rated and owned.
Treat
Controls or exception.
Evidence
Collected from records.
Audit
Reviewed.
- Participants
- Risk owner
- Control owner
- Auditor
- Work items
- Risk
- Control
- Exception
- Evidence
- Automation
- Evidence collection from records
- Exception expiry reminders
- Governance controls
- Exception approval with expiry
- Immutable audit logs where configured
Outcome: Risks are treated and evidence is available on request.
Risk treatment decisions
Each assessed risk receives an explicit treatment — mitigate through controls, accept within appetite, transfer or avoid — recorded with its owner, rationale and review date.
Control testing from operational records
Control tests sample the change, incident, access and supplier records mapped as evidence; failed tests raise findings with corrective actions and owners rather than notes in a workbook.
Policy lifecycle
Policies are drafted, approved, published and reviewed on a cycle; the controls that implement each policy are linked, so a policy change shows which controls and evidence it affects.
Regulatory change
When an obligation changes, impact analysis identifies the mapped controls and risks, so the response is planned against the existing control set instead of a new spreadsheet.
Audit execution
Audits are planned and scheduled, evidence requests are tracked as workflow, findings and observations carry corrective actions, and the audit trail records every step.
Who decides, and what happens when the path breaks
Every decision in the lifecycle has an accountable owner; automation and AI contribute the support listed, never the decision itself.
Decision rights
Treat, accept or transfer a risk
- Decides
- Risk owner
- Support
- Predictive risk scoring as input to the rating (predictive)
Control effectiveness conclusion
- Decides
- Control owner
- Support
- Suggested evidence mapping from operational records (recommendation)
Exception approval and renewal
- Decides
- Governance authority
- Support
- Expiry reminders (workflow-triggered)
Audit conclusions
- Decides
- Auditor
- Support
- Assisted evidence gathering for audit requests (assistance)
Exception register
A control test fails
- Handling
- Finding raised with a corrective action, owner and due date; the control's status reflects the open finding.
- Owner
- Control owner
A control cannot be implemented as designed
- Handling
- Time-bound exception with rationale, compensating measures and expiry; reminders before expiry.
- Owner
- Risk owner, approved by the governance authority
Risk rating exceeds the defined appetite
- Handling
- Escalated for a treatment decision and reported to governance.
- Owner
- Risk owner and governance committee
Security or supplier exception received from another module
- Handling
- Recorded in the register and linked to the originating security incident or vendor assessment.
- Owner
- Risk owner
Owned risks
Each risk has an owner.
Expiring exceptions
Waivers are time-bound.
Audit logs
Actions are logged.
Tenant isolation
Records are scoped to the organization's own environment.
Risk & Compliance in practice
Representative situations drawn from common enterprise security, governance and data patterns.
The audit that used to take a month of preparation
Every audit cycle starts with teams exporting change and access records into spreadsheets and chasing screenshots.
With Nexus: Controls are mapped to the operational records that evidence them, so the auditor's sample is drawn from the change and access records directly, with the control test history alongside.
The waiver that outlived its purpose
A control exception approved by email for a legacy system is still in force three years later, long after the system was meant to be retired.
With Nexus: Exceptions are records with an owner, a rationale and an expiry; reminders precede expiry and an expired exception returns for an explicit renew-or-remediate decision.
One control, three obligations
The same access-review control is tested separately for a security policy, a data-protection obligation and a customer contract.
With Nexus: Control-to-risk-to-obligation mapping lets one tested control evidence every obligation it serves, so the test is performed once and reused with traceability.
Mapped to recognized practice, capability by capability
Each mapping names the Nexus capability and the record that supports the practice. Mappings describe alignment of practice; they are not attestations.
ISO 31000:2018
Aligned practice- Practice
- Risk management process — identification, analysis, evaluation, treatment, monitoring and review
- Nexus capability
- Risk register with qualitative and quantitative scoring, appetite and tolerance definition, treatment plans
- Supporting record
- Risk record: rating, owner, treatment plan, review history
ISO/IEC 27001:2022
Compliance-supporting capability- Practice
- Information security risk assessment and treatment (clauses 6.1.2, 6.1.3, 8.2, 8.3) and evidence supporting the Statement of Applicability
- Nexus capability
- Control library, control-to-risk-to-obligation mapping, control effectiveness testing and evidence collection
- Supporting record
- Control record with linked test results, evidence and exceptions
COBIT 2019
Aligned practice- Practice
- EDM03 Ensured risk optimization · APO12 Managed risk
- Nexus capability
- Risk appetite linkage, control ownership, exception governance and governance reporting
- Supporting record
- Risk register, exception records and governance report packs
How AI supports Risk & Compliance
Risk acceptance and audit conclusions remain with accountable owners.
Assistance drafts or summarizesRecommendation proposes for a person to acceptPredictive forecasts or flagsWorkflow-triggered runs only as configured
- Recommendation
Evidence mapping
Records are suggested as evidence for controls.
- Predictive
Risk scoring
Predictive scoring informs the rating; the risk owner confirms it.
- Recommendation
Control recommendations
Candidate controls are suggested based on the risk profile.
- Predictive
Compliance gap forecasting
Likely compliance gaps are flagged ahead of assessments.
- Assistance
Regulatory change summaries
Regulatory changes relevant to technology operations are summarized for compliance review.
- Predictive
Control failure signals
Patterns in operational data that may indicate a failing control are flagged for the control owner.
- Assistance
Audit preparation
Evidence for audit requests is gathered and assembled for review.
Why enterprises choose Nexus for risk & compliance
Evidence from the work, not for the audit
Change, incident, access and supplier records already in Nexus are mapped as control evidence, so compliance status reflects operations as they happen.
Test once, evidence many
Controls are mapped to every risk and obligation they serve, so one control test supports several requirements with traceability.
Native to operations, complementary to iShieldGRC
Technology risk lives beside the services and changes it concerns; enterprise-wide governance programmes remain the domain of iShieldGRC from iShield GRC Ltd.
How Risk & Compliance connects
Part of the Data, Governance & Intelligence Function, with relationships across Nexus modules and the wider iShield portfolio.
Change Management
Provides change evidence.
Security Operations
Sends security exceptions.
Vendor Management
Links supplier risk.
Crisis Management
Connects continuity risk.
Across the portfolio
What changes for the organization
Continuous compliance
Evidence builds daily.
Controlled exceptions
Waivers reviewed.
Connected risk
Linked to services.
Where this module is used
Integrated GRC & Audit
One control library, one evidence ledger, continuous audit across every framework.
Explore solutionOperational Resilience & Business Continuity
DORA, NIS2 and ISO 22301 aligned — BIA, plans, exercises, crisis and infra DR in one engine.
Explore solutionHybrid & Multi-Cloud Operations
Govern AWS, Azure, GCP and OCI at scale — posture, cost, capacity and policy as code.
Explore solution
