Controls

Your controls are graded continuously from the evidence Joopler collects across your connected systems, not from a once-a-year screenshot. Each control shows a live status, the evidence behind it, who owns it, and where it sits in your workflow.

Statuses

• Pass - the latest evidence meets the control.
• Fail - the evidence shows the control is not met; open it to see the finding and how to fix it.
• Error - a connector could not collect the evidence (for example a broken credential), so the control cannot be graded until the connection is fixed.
• Pending - no evidence yet, usually because the relevant system is not connected.

A control's status rolls up into each framework it maps to, so fixing one control can move several frameworks at once.

Only the controls that apply to you

Joopler grades you against the tools you actually run, so you never see a wall of failing or pending controls for a cloud or vendor you do not use.

Each capability has one plain requirement control - for example "MFA is enforced," "audit logging is on," "vulnerabilities are managed," "network is segmented," "least privilege," "change management," or "background screening." That requirement is always present and always attestable. Underneath it sit per-vendor proof controls (for example MFA on AWS, on Okta, on GitHub) that appear only when you connect that vendor. Their results roll up into the requirement:

• Connect a relevant tool and its proof control appears and feeds the requirement.
• Don't use a given cloud or tool and its proof controls simply never show up.
• With nothing connected, the requirement is still there and you can satisfy it by attesting to it (see below).

So instead of ten separate "MFA in AWS / MFA in Okta / MFA in ..." rows sitting pending, you see one honest requirement, satisfied by whatever you have connected or by your signed attestation.

Owners and workflow

• Assign an owner so a failing control routes to the right person and shows up in their My work inbox.
• Workflow state (to do, in progress, in review, done) tracks the human project management of getting ready, separate from the automated pass/fail.

Evidence and attestation

Open any control to see its evidence history over time (the view an auditor wants for a Type 2 period) and the sample size behind each result.

Every control result is a signed, hash-chained evidence record, so your posture is provable rather than asserted.

Attest a manual control

Some controls are satisfied by a human process rather than by a connector. For those, an owner or admin attests: you write a short statement confirming the control operates, add your name and title, and optionally list a few supporting points (which the assistant can draft for you).

Signing produces a real, branded attestation PDF - your statement, the framework requirements the control satisfies, and a signature block - which is signed, independently timestamped, and hash-chained into your evidence ledger. You can download the PDF, and (with the Google Drive connector) save it to Google Drive. Because it is in the ledger, anyone can confirm it is authentic and unaltered through the public verifier, and the verifier can also check that a downloaded PDF matches the record by its hash.

Manual attestation is only offered for controls that are not already collected automatically. A control graded by a connector or the AI gateway is proven by the live evidence, so there is nothing to hand-sign.

If the control's status later changes, the attestation is flagged stale with a prompt to re-sign so the record reflects the current evidence.

A signed attestation satisfies the control, and it expires

For a control nothing can collect, your signed attestation is the evidence, so signing it moves the control to Pass rather than leaving it Pending.

That only holds while the sign-off is current. An attestation is good for one year:

• 30 days before it lapses, the control is flagged as due for re-signing, on the control itself and in the owner's My work. You see it coming.
• Once it lapses, the control fails. It does not quietly revert to Pending - an expired sign-off is a gap, and a gap should be visible.

Re-signing starts a fresh year. The previous document stays in the ledger, so the history of who attested to what, and when, is never overwritten.

Mark a control Not Applicable

When a control genuinely does not apply to you (for example a laptop control when your workforce runs only managed virtual desktops), mark it Not Applicable with a rationale. The assistant can draft the rationale for you, grounded in your company profile and environment, and you can edit it.

Like an attestation, this produces a signed applicability determination PDF - the rationale and a signature block - timestamped and written into your evidence ledger, and downloadable or saveable to Google Drive. The control then drops out of your score rather than counting as a gap, and the signed determination is on the record for your auditor.

During an audit

When you grant an auditor access for a specific audit period, both attestations and applicability determinations are scoped to that window: your auditor sees the exact, point-in-time signed PDF that was in effect during the period, even if you later re-sign it. The document history is immutable, so re-signing never rewrites what the auditor already reviewed.