Govern

OSI JANUS · Governance, Risk & Compliance Govern continuously.

JANUS is the governance, risk and compliance product of Onion Super Intelligence. It is designed to connect risks, controls, policies, evidence and compliance requirements, so an organization has a continuous view of its security and compliance posture instead of a snapshot rebuilt before each audit.

Platform
OSI – Onion Super Intelligence
Product
OSI JANUS
Role
Govern
Category
GRC · Governance, Risk & Compliance
Status
In development
Access
Design-partner program open
  1. Research
  2. In development
  3. Available

01Why we are building it

Compliance work is real, and the tooling wastes it

Compliance programs often live in spreadsheets that are out of date the day after the audit. Evidence is collected in a rush, controls are marked "implemented" on trust, and the same questions are answered from scratch for every framework and every customer questionnaire. The work is real. The tooling wastes it.

JANUS is a technology platform, designed with the team that delivers Onion’s GRC and compliance services. It is the system that work calls for: one control library, evidence generated by operations, and readiness that can be read from the live system instead of being reconstructed each year. The consulting services remain separate, and remain available.

02Architecture

How it works

Fig. 01JANUS: governance inputs in, continuous governance out

Risks, Controls, Policies, Evidence, Frameworks, Audits feed JANUS, the governance intelligence layer. From it come Security posture, Compliance status, Audit readiness, Remediation tracking.

Governance inputs

  • RisksRegister, owners and treatment
  • ControlsOne library, tested and owned
  • PoliciesVersioned and mapped to controls
  • EvidenceCollected from operations
  • FrameworksRequirements mapped once
  • AuditsFindings and remediation
Governance intelligence layerJANUSRisks, controls, evidence and requirements connected

Continuous governance

  • Security postureRisk and control state, live
  • Compliance statusPer framework, to control level
  • Audit readinessEvidence trail ready to walk
  • Remediation trackingFindings to verified closure
JANUS, design architecture. What it takes in, what it provides, and what comes out. Names and stages may change as the product is built.
  • Flow
  • What OSI provides
  1. Frameworks

    Requirements from each framework mapped to one control library

  2. Controls

    Ownership, status, policy and testing, with cross-framework traceability

  3. Evidence

    Scheduled and, where feasible, automated collection with a versioned trail

  4. Risk

    Register, treatment and posture connected to control state

  5. Readiness

    Live per-framework posture, findings, remediation and auditor exports

Risk

A risk register connected to controls and assets

Risk management is connected to the rest of the program. Risks link to the controls that treat them, the assets they threaten and the owners accountable for them. When a control fails or an assessment finds a gap, the risk picture updates. No parallel spreadsheet is required.

Designed to

  • Risk management with owners, review cycles and treatment plans
  • Risk assessments recorded against the same register
  • Risk-to-control-to-asset traceability
  • Reporting a board can read without translation

Controls and policies

One control library mapped to every framework

Frameworks overlap heavily. One control library maps each control to every requirement it satisfies, so an access review performed once produces evidence for all of them. Policies are versioned and tied to the controls they govern, and control testing records what was checked, by whom and with what result.

Designed to

  • Control management: ownership, operating status and test history
  • Policy management, versioned and mapped to controls
  • Framework management and regulatory mapping to one control set
  • Control testing with results kept as evidence
  • New frameworks added by mapping, not by starting over

Evidence

Evidence collected from operations, continuously

The best evidence is produced by systems doing their normal jobs. JANUS is designed to schedule, collect and file evidence continuously, with owners, due dates and escalation, so the audit file is assembled from work already done and continuous compliance is a state rather than a project.

Designed to

  • Evidence management with scheduled tasks, owners and reminders
  • Evidence collection from common platforms where feasible
  • Versioned evidence trail an auditor can walk through
  • Stale-evidence detection before the auditor finds it

Audit

Readiness is visible before the audit starts

Readiness is a figure to watch, not a feeling. Compliance assessments show which controls need attention for each framework, findings are tracked to verified closure, and auditor-ready packages are exported from the live system.

Designed to

  • Audit readiness per framework, detailed to control level
  • Audit tracking and remediation tracking to verified closure
  • Compliance assessments computed from control state
  • Auditor export packages with evidence references

03Specification

Design specification.

What the product is being designed to be, stated precisely. Everything here is intent: it changes as the product is built and is updated here when it does.

Framework library
ISO 27001:2022, SOC 2, India’s DPDP Act and SEBI CSCRF first, modeled to the same depth. NIST and CIS Controls are planned, added by mapping to the same control library rather than by starting over.
Control model
One control library. Each control maps to every requirement it satisfies across every framework, so a control implemented once produces evidence for all of them. Each control has an owner, an operating status and a test history.
Policy model
Policies are versioned, owned and mapped to the controls they govern, so a policy change shows which controls, evidence and frameworks it touches.
Evidence model
Evidence is scheduled with owners, due dates and escalation, collected from common platforms where feasible and otherwise filed by the owner, and kept as a versioned trail. Stale evidence is detected before an auditor finds it.
Risk model
A register anchored to the business, with owners, review cycles and treatment plans. Risks link to the controls that treat them and the assets they threaten, so the risk picture updates when a control fails or an assessment finds a gap.
Control testing
Tests are recorded against the control: what was checked, by whom, when, and with what result. Results are evidence.
Readiness
Computed live from control state, per framework, to control level. Readiness is a figure to watch between audits, not a feeling before one.
Audit and remediation
Findings are tracked to verified closure. Auditor-ready packages, with evidence references, are exported from the live system.
Third-party risk
Vendor assessments are held in the same system as internal risk, against the same control library.
Boundaries
JANUS keeps the mapping, the evidence and the readiness current. It does not certify anyone, and it does not do the work a control requires. That remains with the organization, and, where wanted, with Onion’s GRC services.

04Designed for

The situations it is being built for.

  • A first certification without a scramble

    A structured path from gap assessment to the audit, with the management system held in the platform instead of a folder of documents.

  • Several frameworks, one set of work

    ISO 27001, SOC 2 and the DPDP Act without tripling the effort: one control set and three sets of evidence output.

  • Posture that is current, not annual

    Risk and control state readable from the live system, so leadership sees where the program stands today rather than at the last audit.

  • Regulated-entity obligations tracked

    SEBI CSCRF requirements held with the audit trail the framework calls for.

  • Second-year audits that are not projects

    Evidence was collected as the work happened, so readiness carries over instead of being rebuilt.

05Who it serves

Built for the people who do the work.

Each role sees the product from where it stands. The last column says which parts of the product that role lives in.

  • 01

    Compliance lead

    Runs several frameworks from one control set, with readiness visible every day rather than reconstructed before each audit.

    Frameworks · Controls · Readiness

  • 02

    Control owner

    Sees the controls they own, the evidence due and the tests recorded, with reminders and escalation instead of a spreadsheet request.

    Controls · Evidence

  • 03

    Risk owner

    Holds a risk that is linked to the controls treating it and the assets it threatens, with treatment plans that can be reported on.

    Risk

  • 04

    Internal audit

    Walks a versioned evidence trail, follows findings to verified closure and exports an auditor-ready package from the live system.

    Evidence · Readiness

  • 05

    Security leader

    Reads posture and readiness in a form a board can understand, and gives a customer a date with something behind it.

    Across the product

06Principles

Design principles

Frameworks overlap, so map once
ISO 27001, SOC 2, the DPDP Act and SEBI CSCRF share most of their requirements. A control is implemented once and mapped to every framework it satisfies.
Evidence from operations
The best evidence is generated by systems doing their normal jobs. The platform is built to collect it there.
Regional regulation is first class
Global standards such as ISO 27001 and SOC 2 sit beside regional ones such as India’s DPDP Act and SEBI CSCRF, modeled to the same depth and not added later as templates.

07Questions

Questions we are asked

No. It is in development. Our GRC and compliance services deliver these outcomes now with established methods, and our compliance specialists advise the product team.

Yes. JANUS is Onion Infosec’s governance, risk and compliance platform. If you are looking for GRC software from Onion Infosec, this is the product.

The first set is ISO 27001:2022, SOC 2, India’s DPDP Act and SEBI CSCRF. NIST and CIS Controls are planned, added by mapping to the same control library. JANUS does not claim to automate compliance with every framework: it keeps the mapping, the evidence and the readiness current, and the organization still does the work the controls require.

The services are delivered by people: scoping, implementing and sustaining a program. JANUS is the software those people wish their clients had. The two stay separate. A client can use either, or both.

No. Certification requires an independent audit. JANUS is designed to prepare an organization for that audit and to give the auditor a clean evidence trail. It does not and cannot certify anyone.

08Design partners

How a design partner works with the team.

Design-partner conversations set what gets built first. This is what the program asks of you, in order, and what it gives back.

  1. A first conversation

    Thirty minutes with the people building the product. You describe what your current tooling gets wrong. We describe what is being built and what is not. Either side can stop there.

  2. A walkthrough of your environment

    What you run, what you already collect and where the gaps are. It is a conversation, not a connection: no data leaves your environment at this stage.

  3. Priorities, written down

    The outcomes that matter most to you become build priorities the team can be held to. You see the list, and you see it change.

  4. Design reviews and early builds

    You review designs before they are built and, when the product is ready for it, run early builds in your own conditions with your own data staying where it is.

  5. What you owe, and what you get

    You owe honest feedback. You get influence over what ships first, early access, and terms agreed before anything is commercial. There is no cost and no commitment on either side.

Need this outcome today?

Being designed and built. The product is not available to buy or deploy, and no release date is given. Its page describes design intent. Design-partner conversations are open. The services below deliver these outcomes now.

Working with us

What every engagement rests on.

Non-disclosure agreements
Every engagement is governed by an NDA. Details of your environment, findings and deliverables stay within the engagement.
Least-privilege access
The minimum access the work requires, tied to named individuals and removed when the work ends.
Telemetry stays in your tenant
In security operations, our analysts work inside your SIEM, EDR or cloud console in preference to exporting logs to systems we run.
End of engagement
Access is handed back, and your information is returned or deleted as agreed with you.

Onion Information Security Solutions Private Limited · CIN U62099MH2025PTC443498 · Registered office in Mumbai, India