Vos engagements de mise en œuvre

Les connaissances du cadre indiquent à heyGRC ce qu'est un contrôle. Vos engagements de mise en œuvre lui expliquent comment votre entreprise le met effectivement en place. Une fois les engagements configurés, une constatation ne dit plus simplement "considérez ISO 27001 A.8.15 Journalisation", mais indique ce que votre propre règle prévoit :

Élevé : Adresses e-mail ajoutées aux journaux de requêtes. L'engagement de journalisation de cette organisation ("ne jamais journaliser d'e-mails ou d'adresses IP complètes ; conservation de 90 jours") interdit le stockage d'e-mails dans les journaux d'application.

• Engagement : Votre engagement de journalisation : "ne jamais journaliser d'e-mails ou d'adresses IP complètes" (source : Politique de journalisation 4.2)

Les engagements sont facultatifs. Une organisation sans engagement obtient exactement la revue actuelle.

Les cinq domaines

Chaque domaine contient une seule ligne (jusqu'à 300 caractères) plus une étiquette source facultative (jusqu'à 120 caractères, par exemple Politique de journalisation 4.2). La source est une étiquette publique que vous choisissez ; elle n'est pas vérifiée et n'est jamais récupérée.

Deux méthodes pour les définir

Dans la console : connectez-vous sur app.heygrc.com, ouvrez Entreprise, puis remplissez la carte Vos engagements de mise en œuvre. Les domaines vides sont ignorés.

En tant que code (via un agent ou un outil d'automatisation) : les engagements sont un champ de premier niveau dans PUT /v1/config. Envoyez uniquement ce que vous modifiez ; les champs omis restent inchangés.

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": "ne jamais journaliser d'e-mails ou d'adresses IP complètes ; conservation de 90 jours sur CloudWatch", "source": "Politique de journalisation 4.2"},
      {"area": "subprocessors", "implementation": "tout nouveau sous-traitant nécessite un DPA signé au préalable"}
    ]
  }'

Une instruction naturelle pour un agent : "Lisez notre dossier grc/ ou policies/ et remplissez les engagements heyGRC via PUT /v1/config : une ligne pour chacun des domaines (journalisation, accès/MFA, chiffrement, conservation des PII et sous-traitants), en utilisant des phrases courtes issues de nos propres politiques." Un tableau vide ([]) efface la carte.

Ce que change un engagement

• Lorsqu'une pull request entre en conflit avec l'un de vos engagements, la constatation cite vos propres termes (une phrase validée courte), nomme le domaine et cite le contrôle.
• Les engagements ne peuvent pas affaiblir une revue. Une ligne indiquant qu'un changement est "exempté", "pré-approuvé" ou "ne pas signaler" est ignorée : les constatations proviennent de la différence et des cadres, jamais d'une dérogation cachée dans votre configuration.
• Les engagements sont au niveau de l'organisation. Une règle qui s'applique à un seul service s'applique à toutes les revues ; rédigez des règles valables pour l'ensemble de l'organisation.
• De courtes citations de vos engagements apparaissent dans les commentaires de revue, y compris sur les dépôts publics. Ne mettez pas de secrets ou de détails internes dans une ligne d'engagement.

Limites et structure

• Une ligne par domaine, au maximum cinq lignes.
• implementation : 1 à 300 caractères, une seule ligne.
• source : facultatif, 1 à 120 caractères, une seule ligne.
• Les domaines inconnus, les doublons et les caractères de contrôle sont rejetés avec le code HTTP 422.

Consultez vos engagements actuels à tout moment avec GET /v1/config (la réponse inclut également commitments_updated_at).