One standard
Software that implements IFRS S2 and nothing else.
There is no framework selector. The product opens a cycle with the same 33 disclosure items for every customer, each referenced to the paragraph it comes from. That is a design decision with real consequences in both directions, and the ones that cost you something are set out on this page instead of surfacing on the second call.
What breadth requires
A multi-framework tool has to be built generically.
Frameworks disagree. They draw the reporting boundary differently, apply different materiality tests, and ask for different granularity on the same underlying figure. A product that serves several at once therefore cannot hard-code any one of them: it needs a general datapoint store and a mapping layer that projects those datapoints into whichever framework you have switched on.
That is the correct architecture for the problem, and for a group reporting under three regimes from one dataset it is the only sane answer. But it has consequences that follow from the design rather than from anyone's execution. Your requirement list becomes a configuration rather than a fixed list, so no two customers are looking at the same checklist. Guidance has to be written generically enough to stay true under every framework a field can be mapped to, which means it cannot cite a paragraph. And completeness becomes a property of your configuration, so the question are we done has a different answer for each account.
The boundary
What is inside, and what is not.
What narrowness buys
Four things a fixed requirement set makes possible.
The list can be enumerated. Thirty-three items, the same thirty-three for everyone, visible before you buy. There is no scoping exercise to establish what your instance will contain, because there is only one instance shape.
Guidance can cite rather than paraphrase. Each item carries the paragraph it comes from. A generic datapoint cannot do that without picking a framework, and picking a framework is the thing a generic datapoint exists to avoid.
Completeness is computable. Progress is measured against a known denominator, and against what has cleared review and approval rather than what has been drafted. When the denominator is a configuration, a progress bar is a statement about your setup as much as your work.
The output has one shape. One kind of engagement, one archive structure, one manifest format — which is why the export can be a fixed artefact and why the price can be a fixed number. Both of those follow from this page, not the other way round.
Why 33
The items are smaller than the paragraphs.
The 33 tracked items are cut at sub-paragraph level, because a requirement that cannot be assigned to one person is not a control. Governance is the clearest case: in the standard it is three paragraphs, and paragraph 6 alone asks for several distinct things about oversight. We split it into the seven things it actually asks for, so each one has an owner, an evidence slot and a state of its own.
One clarification, because the arithmetic invites a mistake. The core content of IFRS S2 also happens to run to 33 paragraphs. That is a coincidence, not a mapping — they are different counts of different things, and the per-pillar breakdown on the product page gives both side by side. If you are scoping the work itself and not the software, the standard's own structure is the better starting point.
Overlap with other regimes
Reusable is not the same as produced.
A large share of what IFRS S2 asks for also appears, in some form, in ESRS E1 and in the older TCFD structure. Interoperability guidance published by the standard setters exists precisely to make that overlap usable, so the governance description, risk process and metrics you prepare here are not wasted if you later report elsewhere.
The distinction that matters commercially is that the product does not produce output for those regimes. You would be carrying content across by hand, not exporting it. If you want the requirement-level comparison before deciding, the crosswalk sets out where the standards line up and where they genuinely diverge.
The limit
Who should not buy this.
If you are in CSRD scope and filing under ESRS, this is the wrong tool on its own. If you complete a CDP questionnaire every year, or report under GRI, or need SASB disclosures outside the cross-industry climate metrics, none of that comes out of here. Running a single-standard product alongside a broader one is a real option, but it means two systems and two sets of evidence to keep aligned, and you should price that in rather than discover it.
A second limit follows directly from the argument above, and it is the sharpest one. The ten items in the metrics pillar are the cross-industry metric categories and targets. IFRS S2 also expects industry-based metrics, informed by the industry guidance in its appendix, and those are not broken out as tracked items — they differ by sector, which is precisely the kind of thing a fixed list cannot hold. If your sector's metrics are the difficult part of your disclosure, that work sits outside the checklist.
Third, this is a disclosure-controls product, not a carbon accounting platform. Scope 1 and 2 are calculated; Scope 3 is deliberately light, a supplier survey, not a category engine. If your hard problem is measuring a complex value chain rather than evidencing and signing off what you disclose, that is the constraint you will feel first.
The honest summary is that the product is good for one job and refuses the others. Worth knowing before you spend a cycle finding out.
When the standard moves
Amendments are product work, not a new module.
Standards change. The ISSB amended the greenhouse gas requirements in 2025, and a single-standard product absorbs that as a change to the item set, guidance and validation rather than as a new framework to configure. We have written up what those amendments changed separately.
The trade runs the other way too, and it belongs here, not in a footnote: a product with one standard in it carries one standard's worth of risk. If IFRS S2 adoption stalls in your jurisdiction, a broader platform has somewhere else to go and this does not. The deadline checker will tell you where your jurisdiction currently stands.
Questions
Three about the scope decision.
Will you add ESRS or GRI support?
Not on any timetable you should plan around. Adding a second framework means adding the mapping layer described at the top of this page, and that changes the product into the other kind of product. If that is what you need, you need it now, and you should buy it now.
Can I run this alongside a multi-framework platform?
Yes, and some will. The archive exports as PDF and CSV with a manifest, so the content is portable. What does not transfer is the sign-off state, so decide which system is the record of approval before you split the work between two.
What happens to my data if the standard changes materially?
Item definitions change, and the activity log keeps the history of what was approved under the previous version. Nothing is rewritten in place; that is the whole point of an append-only log.
Next
Read the coverage before you decide.
The per-pillar breakdown, the paragraph references and what the export contains — all on one page, nothing gated.
Related: evaluating without a sales call · an audit trail you can test