11.04 Scheduled Reports

Why this matters

GRC programs run on cadence: weekly digests of new risks, monthly executive summaries, quarterly compliance posture reports, annual board reports. Most stakeholders want these emailed to them rather than logging into SimpleRisk to pull them — and emailed automatically, not as a manual task on the GRC team's plate every week.

The honest scope to know up front: SimpleRisk Core doesn't have a built-in scheduled-reports feature. There's no "Configure → Scheduled Reports" page where you set up "every Monday at 8 AM, send the Dynamic Risk Report to these recipients." This article exists to spell that out and walk through the alternatives that do work.

The alternatives are mature enough that programs running scheduled reports against SimpleRisk are common; the lack of native support is a configuration gap, not a capability gap. You just have to choose your alternative.

Alternative 1: Cron-driven script + email

The most common pattern. A script runs on cron schedule, hits the SimpleRisk API, generates a report file (CSV, PDF, HTML, Excel), and emails it to the configured recipients.

Architecture

[cron] → [report script] → [SimpleRisk API] → [response] →
    → [report formatter] → [SMTP] → [recipient inboxes]

The script lives outside SimpleRisk (typically on a server next to it, or on a workflow-automation host). It uses an API key bound to a SimpleRisk integration user.

Example: weekly Critical risks digest

#!/usr/bin/env python3
"""Weekly digest of all open Critical risks."""
import os
import smtplib
from email.message import EmailMessage
import requests

API_URL = os.environ['SIMPLERISK_URL']
API_KEY = os.environ['SIMPLERISK_API_KEY']
SMTP_HOST = os.environ['SMTP_HOST']
SMTP_USER = os.environ['SMTP_USER']
SMTP_PASS = os.environ['SMTP_PASS']
RECIPIENTS = os.environ['RECIPIENTS'].split(',')

# Fetch open Critical risks
response = requests.get(
    f"{API_URL}/api/v2/risks",
    headers={"X-API-KEY": API_KEY, "Accept": "application/json"},
    params={"status": "open"},
    timeout=30,
)
risks = [r for r in response.json().get("data", []) if r.get("calculated_risk", 0) >= 8]

# Build the report
lines = ["Weekly Critical Risks Digest", "=" * 30, ""]
for risk in risks:
    lines.append(f"  {risk['id']}: {risk['subject']} (score {risk['calculated_risk']}, owner {risk.get('owner_name', '?')})")
lines.append("")
lines.append(f"Total: {len(risks)} open Critical risks")
body = "\n".join(lines)

# Send the email
msg = EmailMessage()
msg['Subject'] = f"Weekly Critical Risks Digest — {len(risks)} open"
msg['From'] = SMTP_USER
msg['To'] = ", ".join(RECIPIENTS)
msg.set_content(body)

with smtplib.SMTP_SSL(SMTP_HOST, 465) as smtp:
    smtp.login(SMTP_USER, SMTP_PASS)
    smtp.send_message(msg)

print(f"Sent digest to {len(RECIPIENTS)} recipients with {len(risks)} risks")

Cron entry

# Every Monday at 8 AM
0 8 * * 1 /usr/local/bin/simplerisk_weekly_digest.py

Adapting the pattern

• Different schedule: monthly, daily, hourly — adjust the cron entry.
• Different content: query different endpoints; format differently; include attachments (CSV, PDF).
• Different recipients: a per-team digest can pull team-specific risks and email each team's lead.
• Different format: CSV attachment for spreadsheet use; HTML body for in-line viewing; PDF for formal reporting.

Pros and cons

Pros: - Full control over content, format, schedule, recipients. - Decoupled from SimpleRisk upgrades. - Repeatable (script under version control).

Cons: - Requires writing and maintaining the script. - Requires hosting (a server with cron and outbound SMTP). - Requires monitoring (script failures need to surface).

This is the right pattern for most programs.

Alternative 2: Workflows Extra with scheduled trigger

If your install has the Workflows Extra and supports scheduled triggers (some Extra versions do, some don't), you can build a workflow that fires on schedule and dispatches an email.

Architecture

The workflow has a schedule trigger (e.g., schedule.weekly, schedule.monthly). When fired, the workflow:

1. Queries the relevant data (often via a webhook to a script that returns the report content).
2. Formats the data via the workflow's variable substitution.
3. Dispatches via Send Email action.

Pros and cons

Pros: - Configured in SimpleRisk's UI rather than externally. - Same operational model as event-driven workflows.

Cons: - Workflow data-querying is limited (the workflow can pass IDs to webhooks but doesn't natively run SQL or complex queries). - Schedule trigger support varies by Workflows Extra version. - Less flexible than a custom script.

For programs already using the Workflows Extra heavily, this is worth checking. For new deployments, alternative 1 is usually simpler.

Alternative 3: External BI tool pulling on schedule

For programs running a BI platform (Tableau, Power BI, Looker, Metabase, Grafana), the platform typically has built-in scheduled-report features:

1. The BI tool connects to SimpleRisk via the API (using an integration user's API key).
2. The tool runs queries on schedule.
3. The tool generates the report and dispatches via its own delivery channels (email, Slack, dashboard publication).

Pros and cons

Pros: - BI tools have rich visualization, formatting, and scheduling features. - Centralized reporting infrastructure (if you already have a BI platform). - Self-service for stakeholders (they can build their own scheduled reports).

Cons: - Requires a BI platform. - Requires integration setup. - May involve license cost.

For programs already running a BI platform, this is often the path of least resistance.

Alternative 4: Workflow automation platform

Tools like Zapier, Make.com, n8n, or Tines can poll SimpleRisk on schedule, transform the data, and dispatch.

Pros and cons

Pros: - No code (configured in their UI). - Dispatches to many destinations (email, Slack, Teams, Trello, custom webhooks). - Some support free tiers for low-volume use.

Cons: - Per-task or per-integration cost at scale. - Vendor lock-in. - Data flows through their service.

For programs that already use these tools for other automation, adding a SimpleRisk-driven schedule is often quick.

Alternative 5: Embed a "click here to see the current report" link

Sometimes the right answer is "don't email the report; email a link to it." Recipients click the link, log into SimpleRisk, see the current state.

For executives who view the program through SimpleRisk anyway, this works. For stakeholders who don't have SimpleRisk access, it doesn't.

What to consider when choosing

• Have engineering capacity, want full control: Alternative 1 (script)
• Already running BI platform: Alternative 3 (BI tool)
• Already using Workflows Extra heavily: Alternative 2 (workflow)
• Already using Zapier / etc.: Alternative 4 (workflow platform)
• Don't need an actual file, just a link: Alternative 5 (link only)
• Stakeholders won't log into SimpleRisk: Alternative 1, 3, or 4
• Tight regulatory data-residency: Alternative 1 (in-house) or 3 (with on-prem BI)

Most programs land at alternative 1.

Common patterns to script

Recurring report patterns:

• Weekly digest: open Critical risks, new risks since last week, mitigations completed.
• Monthly summary: total open / closed / pending review counts; level distribution; SLA status.
• Quarterly compliance posture: framework pass rates, audit completion, control test results.
• Annual board report: top risks, year-over-year trends, key incidents, framework maturity.
• Per-team weekly: risks for a specific team, mitigations owned by team members, upcoming reviews.
• Per-owner: risks owned, reviews due soon.

Each pattern is a query plus a format. Build once; schedule; repeat.

Operational considerations

• Monitoring: script failures should alert someone. Email send failures, API failures, format errors. Don't let scheduled reports silently stop working.
• Recipient management: as people leave or join teams, recipient lists drift. Periodic review.
• Format evolution: the report format that worked two years ago may not match today's program. Refresh.
• Template / content discipline: pre-defined templates plus variable data > ad-hoc each time.
• Sender reputation: scheduled reports go to large recipient lists; sender domain authentication (SPF/DKIM/DMARC) matters.

Common pitfalls

A handful of patterns recur with scheduled reports.

• Building scheduled reports without monitoring. A script that silently stops sending after Quarter 2 produces "where's our weekly digest?" complaints in Quarter 3.

• Sending to too many recipients. Scope creep produces email-fatigue and unsubscribes (which can hurt sender reputation).

• Reports that don't change content week-to-week. Recipients learn to ignore. Tune content to focus on what's worth acting on.

• Not version-controlling the script. "It worked when Bob wrote it; Bob left; nobody remembers what it does."

• Using the same API key across many integrations. Rotate one and break the others. One key per integration.

• Not tuning the report for the audience. Executives want a 1-page summary; analysts want the full data. Different reports for different audiences.

• Building over-elaborate reports because you can. A 20-page weekly report is a 20-page weekly report nobody reads. Start simple.

• Treating scheduled reports as a substitute for review meetings. Reports inform; meetings decide. Don't replace the conversation with the email.

• Letting reports become wallpaper. Periodically check whether anyone reads them; cancel ones that don't add value.

• Generating reports during high-traffic windows. A weekly report that pulls 50,000 risks at 9 AM Monday spikes load when users are arriving. Schedule overnight.

Related

• The Audit Trail
• The Debug Log
• Compliance Evidence Export
• Building a Script Against the API
• Using the API for Integrations
• The Cron Jobs
• Email and the Notification Extra
• What the Workflows Extra Does