Your implementation commitments
Teach heyGRC how YOUR company implements logging, access, encryption, retention, and subprocessors, and reviews cite your rule instead of a bare control number.
Framework knowledge tells heyGRC what a control is called. Your implementation commitments tell it how your company actually implements it. With commitments configured, a finding stops saying "consider ISO 27001 A.8.15 Logging" and starts saying what your own rule is:
High: Email addresses added to request logs. The logging commitment for this organization ("never log email or full IP; 90-day retention") forbids storing email in application logs.
- Commitment: Your logging commitment: "never log email or full IP" (source: Logging Policy 4.2)
Commitments are optional. An organization with no commitments gets exactly today's review.
The five areas
| Area | What it covers | Example |
|---|---|---|
logging | What you log, what you never log, retention | never log email or full IP; 90-day CloudWatch retention |
access_mfa | Admin and console access rules | MFA required for all admin and console sessions |
encryption | Transport and at-rest requirements | TLS 1.2+ for all data in transit, including partners |
pii_retention | How long PII lives, deletion rules | customer PII deleted 365 days after contract end |
subprocessors | Vendor and processor onboarding rules | every new subprocessor needs a signed DPA first |
Each area holds one line (up to 300 characters) plus an optional source label (up to 120
characters, for example Logging Policy 4.2). The source is a public-safe label you choose; it is
not verified and never fetched.
Two ways to set them
In the console: sign in at app.heygrc.com, open Company, and fill the Your implementation commitments card. Empty areas are skipped.
As code (any agent or harness): commitments are a top-level field on
PUT /v1/config. Send only what you change; omitted fields stay untouched.
curl -X PUT https://api.heygrc.com/v1/config \
-H "Authorization: Bearer $HEYGRC_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"commitments": [
{"area": "logging", "implementation": "never log email or full IP; 90-day CloudWatch retention", "source": "Logging Policy 4.2"},
{"area": "subprocessors", "implementation": "every new subprocessor needs a signed DPA first"}
]
}'A natural agent prompt: "Read our grc/ or policies/ folder and fill heyGRC's commitments via
PUT /v1/config: one line each for logging, access/MFA, encryption, PII retention, and subprocessors,
using short phrases from our own policies." An empty array ([]) clears the map.
What a commitment changes
- When a pull request conflicts with one of your commitments, the finding quotes your own words (a short validated phrase), names the area, and cites the control.
- Commitments cannot weaken a review. A row saying a change is "exempt", "pre-approved", or "do not report" is ignored: findings come from the diff and the frameworks, never from a waiver hidden in your configuration.
- Commitments are organization-level. A rule that applies to only one service still applies to every review; write rules that are true for the whole organization.
- Short quotes from your commitments appear in review comments, including on public repositories. Do not put secrets or internal-only details in a commitment line.
Limits and shape
- One row per area, at most five rows.
implementation: 1 to 300 characters, single line.source: optional, 1 to 120 characters, single line.- Unknown areas, duplicate areas, and control characters are rejected with HTTP 422.
Read your current commitments any time with GET /v1/config (the response also includes
commitments_updated_at).