Multi-platform governance

01Governing access, not a publisher's catalog #sec_cae89bbf

An organization never entrusts all its access to a single technology. Identities live in a directory, teams work in collaborative spaces, code in repositories, data in business platforms, and privileges in infrastructure services. As the information system evolves, new solutions appear without immediately making the previous ones disappear.

REVIEWIT is designed to govern this diversity without depending on the vocabulary of a particular publisher. Its object is not Microsoft 365, Google Workspace, GitHub, Jira, Slack or any other platform taken in isolation. Its object is the access relationship that must be reviewed: an identity or group has a right to a resource, within a given scope, with elements that allow a person to judge its legitimacy.

This separation is the foundation of the multi-platform approach. Solutions may change; the governance question remains the same: who accesses what, in what capacity, and should this access still be maintained?

02A common model that retains useful differences #sec_45846948

Platforms do not describe their objects in the same way. One speaks of groups, another of teams; one exposes sites and folders, another projects, repositories or channels; access levels may be called member, administrator, contributor, editor or reader.

REVIEWIT does not replace all these terms with an impoverished generic object. It organizes them according to a stable hierarchy:

• a solution designates the connected system;
• a workload represents a functional family of this solution;
• a resource is the concrete object likely to be inventoried and recertified;
• identities, memberships, roles and permissions explain the access relationship;
• elements of proof, such as the owner or the last known activity, give the reviewer the necessary context to decide.

A collaborative site, a code repository and a project therefore do not become the same object. They remain different, but their access relationships can be processed by the same campaign cycle, the same responsibilities and the same proof requirement.

03The connector translates; it does not redefine REVIEWIT #sec_4c40d9f9

Each solution has its APIs, authentication modes, limits, pagination and visibility rules. The role of a connector is to handle these particularities and then present data compliant with the common contract to REVIEWIT.

This boundary avoids building a different application for each publisher. Once the data is collected and qualified, the rest of the chain remains shared: scope selection, policy association, campaign construction, assignment to reviewers, decision, justification, restitution and audit trail.

The principle also applies to the connection experience. The fields and controls specific to a solution are declared by its connectivity provider as much as possible. A specific screen is only justified when a behavior cannot be described otherwise, for example an authorization redirection or a scope discovery after authentication. The extension thus remains explicit and testable, without duplicating the entire interface.

04Extending coverage by contract #sec_7a65dcc5

Adding a platform is not just about calling an API. A usable extension must provide a complete chain.

It first declares the solutions, workloads and resources it can actually observe. It then describes the form of each resource: its stable identifier, the information presented to the reviewer and the attributes that carry an identity, an owner, members or an activity.

These attributes are matched to a governed vocabulary. It is this matching that allows evaluators to understand, independently of the publisher, that a field represents, for example, owners, members or guests. A policy is only proposed when the necessary data actually exists for the workload concerned.

Finally, the connector must demonstrate its operational behavior: authentication according to the least privilege, read-only collection, pagination, recovery after error, reconciliation and traceability. An integration is not considered complete because a first API response has been obtained; it must provide measurable and repeatable coverage.

This contract creates a controlled extension: a new solution joins the platform by adding its language and collection capability, without rewriting the campaign engine or the responsibility rules.

05A common policy, only when it makes sense #sec_afa8f799

Agnosticism does not mean that the same policy applies indiscriminately to all objects. A membership, ownership, inactivity, external sharing or privileged access policy requires different information. Some resources carry this information; others do not.

REVIEWIT therefore links policies to the workloads for which they are founded. A workload can be declared in the catalog while remaining non-governable as long as no applicable policy or sufficient data is associated with it. This distinction prevents promising recertification where the connector only provides an inventory.

The platform remains common, but the applicability remains honest. Two solutions can participate in the same campaign when their objects meet the same governance need; they are never forced into an artificial equivalence.

06Coverage is a fact, not an assumption #sec_8e9dedd6

A valid connection does not guarantee that the entire tenant is visible. Coverage depends on the permissions granted, the installation scope, the API's capabilities and sometimes the edition subscribed to by the publisher. A connector can be technically healthy while only seeing a portion of the expected resources or accesses.

REVIEWIT therefore separates connection health from collection coverage. This distinction is essential in a multi-platform environment: it allows to say that an authentication works without presenting a partial inventory as exhaustive.

Campaigns and their readers can thus know the limit of what is observed. The absence of an object does not silently become proof of an absence of access.

07A gradual adoption, without dependence on a single platform #sec_d8c98cfe

An organization can start with the solution that carries its most immediate risk, then gradually extend the scope. New connectors enrich coverage; they do not create a new governance method to learn or a new evidence trail to exploit.

This continuity reduces dependence on a single vendor. A change in collaborative tool, code repository, or business platform changes the data source, but not the principle of campaigns, the role of reviewers, or the way to demonstrate the decisions made.

The approach covers both SaaS services and cloud environments or systems operated on-site, as long as a connectivity provider satisfies the collection and evidence contract. REVIEWIT does not impose a source technology; it does, however, impose the minimum quality necessary to govern what it exposes.

08What ‘multi-platform’ does not promise #sec_24071a82

The catalog of possible solutions and the list of actually available connectors are not the same thing. The presence of a solution in a repository describes an extension model or a coverage target; it does not in itself constitute the announcement of a delivered and supported connector.

Similarly, REVIEWIT does not become the master directory of connected platforms and does not write in their contents to harmonize them. It collects the relationships useful for recertification, organizes human judgment, and retains proof of this judgment. The execution of a revocation in the source system remains a distinct capability, which must be announced and demonstrated when it exists.

REVIEWIT’s agnosticism is therefore an architectural and governance property, not a vague promise of universality.

09In summary #sec_f36382e4

REVIEWIT separates the business of recertification from the particularities of source platforms. Connectors translate identities, groups, roles, permissions, resources, and evidence into a common contract; the campaign engine, responsibilities, and audit trail remain shared.

This architecture allows for the gradual extension of coverage without building silos by publisher. It retains useful differences, measures visibility limits, and only applies a policy when the data makes it truly governable.

Solutions change. The need to know who accesses what—and to be able to prove who decided—remains.