Submissions

The Submissions module is where your organization tracks every formal package it owes to someone outside (or sometimes inside) the workspace: a regulator report, an incident notification, a certification attestation, a customer assurance response, a management statement, a disclosure. Each is a piece of work that must be assembled, reviewed, sent, and acknowledged, with a paper trail of every state transition.

Submissions sit at the boundary between your governance program and the recipients who consume its outputs. They are what the program ships.

When you would reach for this

You set up submissions when:

A regulator requires a periodic report (annual compliance attestation, quarterly transaction return, post-incident notification within a defined window).
A customer or counterparty asks for an assurance response (a SOC 2 report, a security questionnaire, a third-party risk assessment).
A certification or accreditation body requires evidence packages on a cycle.
An incident triggers a required notification with a specific recipient and a tight clock.
A management statement (a board declaration, an attestation, a disclosure) must be delivered with a recorded chain of custody.
A customer audit response needs to be assembled from multiple internal records and submitted with a tracked outcome.

You don’t reach for this when capturing the obligation that requires the submission (that’s Obligations) or the underlying evidence the submission relies on (that’s Evidence). Submissions is the package and delivery activity.

What lives in a submission

Three record types:

Submission requirement is the durable expectation: “we must submit this kind of package to this recipient on this cadence.” It carries a title, a stable key, a submission kind, a recipient snapshot, a trigger policy (what kicks off a new package), a due-date policy, and a package-content policy (what the package must contain).

Submission package is one concrete instance of a submission. It carries a title, a due date, a status, the recipient, the underlying documents and evidence claims, and (when complete) the actor who submitted, the timestamp, and any audit-package reference.

Submission event is one state-change record on a package: created, reviewed, approved, submitted, receipt-received, rejected, withdrawn, resubmitted, closed. Each event captures the actor, the timestamp, and a snapshot of the relevant detail.

Submission kinds

Common kinds:

Kind	Meaning
`incident_notification`	Notification to a regulator, customer, or other party about an incident. Time-bound.
`regulator_report`	A periodic or event-driven report owed to a regulator.
`certification_attestation`	An attestation package supporting a certification cycle.
`customer_assurance`	A response to a customer’s assurance request (SOC 2 share, security questionnaire).
`management_statement`	A formal management statement or declaration.
`disclosure`	A required disclosure (financial, regulatory, public).
`custom`	Any other submission kind your organization tracks.

Package statuses

The lifecycle a submission package walks:

Status	Meaning
`draft`	The package is being assembled.
`in_review`	Submitted to internal reviewers for sign-off.
`approved`	Internally approved; ready to send.
`submitted`	Sent to the recipient.
`accepted`	The recipient confirmed acceptance.
`rejected`	The recipient rejected the package. Typically requires resubmission.
`withdrawn`	The organization withdrew the submission before acceptance.
`superseded`	A newer package has replaced this one.
`archived`	The package is archived.

Event kinds (created, reviewed, approved, submitted, receipt_received, rejected, withdrawn, resubmitted, closed) drive the status transitions and are the primary write surface for external systems.

A worked example: an industrial chemicals manufacturer tracks regulatory submissions

A chemical manufacturer produces products under several regulatory regimes: environmental discharge reports, product registration filings, safety data sheet updates, incident notifications for any release event. The compliance director, Annika, wants every submission tracked from due date to recipient acknowledgement, with audit-grade evidence of the chain.

She sets up Submissions like this.

Step 1: define requirements. Annika walks each regulatory regime the company operates under and creates a submission requirement per recurring filing:

quarterly-environmental-discharge — kind regulator_report, recipient is the environmental agency, due-date policy: 30 days after each quarter-end, package content: discharge volume data, lab results, narrative.
annual-product-registration-renewal — kind regulator_report, recipient is the product safety authority, due-date policy: 60 days before each anniversary.
safety-data-sheet-revision — kind disclosure, recipient is downstream customers, due-date policy: within 90 days of substance change, triggered by composition change.
incident-release-notification — kind incident_notification, recipient is the environmental agency emergency line, due-date policy: 24 hours from incident detection, triggered on incident classification.

Step 2: package creation. As due dates approach (or triggers fire), the system creates a draft package per the requirement’s policy. For the quarterly discharge report, packages are created automatically at quarter-end with the prior quarter’s data attached.

Step 3: assemble and review. The compliance team assembles each package: data exports, lab results, narrative. The package is routed for internal review (kind = reviewed event), then for approval (kind = approved event).

Step 4: submit. Once approved, the package is submitted to the recipient. The team records the submission as an event (submitted kind, with the timestamp and delivery method captured in the event snapshot).

Step 5: receipt and outcome. When the recipient acknowledges or rejects, an event is recorded (receipt_received or rejected kind). The package status updates accordingly.

Step 6: incident notification flow. When the environmental control monitors detect a release event, the incident notification submission requirement triggers automatically. The clock starts. The compliance team has 24 hours to deliver the package. The system surfaces the open package prominently in the inbox; status walks from draft through submitted to receipt_received typically within hours. The evidence trail of “we notified within window” is the package itself.

Step 7: customer assurance responses. Separately, customers occasionally send security questionnaires. Each becomes a customer_assurance submission package. The compliance team assembles the response from existing evidence claims and DMS documents, routes for review, submits, and tracks the customer’s acceptance.

After a year:

The submission register is a full history of every regulatory filing, customer assurance response, attestation, and incident notification with their delivery posture.
Late or overdue packages are surfaced.
A regulator can be shown “every submission delivered to you, with timestamps and your receipt acknowledgements.”

What you’ll see in the product

Submissions lives under Governance → Submissions in the workspace.

Two top-level tabs: Requirements and Packages.

The Requirements list shows every recurring or event-driven submission requirement with kind, recipient, trigger policy, due-date policy, and the count of packages under it.

Inside a requirement, you see the policies that drive package creation and the history of packages produced.

The Packages list is the operational workspace: every package with status, recipient, due date, owner. Filter by status, kind, recipient, due-date range. This is the page compliance teams live in.

Inside a package, you see:

The full title and description.
The recipient snapshot.
The current status and event history.
Linked documents (the package’s content, from the DMS).
Linked evidence claims (referenced in the package).
Linked audit package, if the submission references one.
Internal review state (which reviewers, which approvals).
The complete event log: created, reviewed, approved, submitted, receipt-received, etc.
Activity history.

Every change is captured in the workspace Audit Log.

Common workflows

Defining a recurring submission

Submissions → Requirements → New requirement. Pick the kind, recipient, trigger and due-date policy.
Define what the package must contain.
The system creates packages automatically per the trigger policy (or you create them manually).

Assembling and submitting a package

Packages → [draft package]. Assemble the content (link documents, evidence claims).
Route for review (reviewed event).
Receive approval (approved event).
Submit to recipient (submitted event, capturing delivery method and timestamp).
When recipient acknowledges, record (receipt_received event).

Handling rejection

Recipient rejects; record a rejected event with rationale.
Address the rejection reason; create a new package (or revise) and resubmitted event.
Track the resubmission through the standard flow.

Withdrawing a package

Before acceptance, transition with a withdrawn event and rationale.
The package’s status moves to withdrawn.
A replacement package can be created if applicable.

Incident-driven submission

An incident triggers the submission requirement automatically (configured trigger policy).
The clock starts at trigger time.
The package is surfaced prominently; the team works the submit flow inside the SLA window.

Looking for the API?

See Submissions API reference for the v1 REST endpoints to read requirements and packages, and to record submission events from external systems (e.g., a regulator portal callback or a customer assurance platform).

Obligations - obligations create submission requirements.
Evidence - submissions cite evidence claims.
Audit Packages - submissions can reference audit packages.
Frameworks - framework requirements drive periodic submissions.
Findings - findings may trigger incident-notification submissions.