Compliance — RENAR как audit trail infrastructure

RENAR — стандарт инженерии требований; не compliance-стандарт сам по себе. Но RENAR предоставляет инфраструктуру traceability, которая делает соответствие другим стандартам (ISO 27001, GDPR, ФЗ-152, EU AI Act и др.) проверяемым автоматически. Эта глава — mapping артефактов RENAR на 8 ключевых compliance фреймворков + self-assessment checklists для compliance teams + список auto-generated artifacts для аудитора.

Предпосылки: RENAR Core, reference/02-schemas.md (frontmatter schemas), reference/03-ai-risk-register.md.

1. Принципы compliance в RENAR

1.1 Compliance — first-class artifact

Каждое требование с регуляторным обоснованием обязано иметь поле compliance во frontmatter:

compliance:
  - standard: "ISO 27001:2022"
    control: "A.5.34"
    rationale: "Privacy and protection of PII — требование шифрования персональных данных"
  - standard: "GDPR"
    article: "Art.32"
    rationale: "Security of processing"
  - standard: "ФЗ-152"
    article: "ст.19"
    rationale: "Меры по обеспечению безопасности персональных данных"

Поле повторяемое — одно требование может закрывать controls сразу нескольких стандартов.

1.2 Data classification как обязательное расширение

Каждое BR / SR, оперирующее данными, обязано декларировать классификацию:

data-classification:
  contains-pii: true                  # GDPR / ФЗ-152 trigger
  contains-financial: false           # PCI-DSS trigger
  contains-health: false              # HIPAA / 152-ФЗ спец. категории trigger
  contains-children-data: false       # COPPA trigger
  retention-days: 1095                # 3 года
  data-residency: ["RU", "EU"]        # где разрешено физически хранить

При contains-pii: true — автоматически становятся обязательными SR-encryption, SR-audit-log, SR-erasure (см. §3, §4, §5 ниже).

1.3 Traceability как audit foundation

RENAR traceability BR → SR → SPEC → TC → реализация → CI run — это и есть audit trail. Аудитор открывает coverage report и видит:

  • Какие требования закрывают конкретный compliance control.
  • Какие TC их верифицируют.
  • Когда прошёл последний прогон (last-run.date).
  • В какой requirement-version зафиксирована текущая редакция.

Время аудита: 1-2 дня вместо 2-3 недель. Capability V6 (drift detection) обеспечивает, что evidence не «протух» между аудитами.

2. ISO/IEC 27001:2022 — Information Security

2.1 Mapping Annex A controls

ISO 27001:2022 Annex A controlRENAR-артефакт
A.5.7 Threat intelligenceSPEC-SEC с threat model; SR с compliance: A.5.7
A.5.8 Information security in project managementСам RENAR как process compliance
A.5.34 Privacy and protection of PIISR с шифрованием + data-classification.contains-pii: true
A.6.3 Information security awarenessOnboarding процесс включает чтение RENAR
A.8.1 User endpoint devicesSR с device requirements (если в scope)
A.8.5 Secure authenticationSR-AUTH-* + SPEC-SEC с authentication flow
A.8.7 Protection against malwareSR + adversarial review (AI-критик)
A.8.10 Information deletionSR с deletion logic + data-classification.retention-days
A.8.16 Monitoring activitiesSR с logging + SPEC-OPS audit-log requirements
A.8.24 Use of cryptographySR с явным crypto algorithm + ISO 25010 Security characteristic
A.8.25 Secure development life cycleSENAR + RENAR как evidence
A.8.28 Secure codingTC с security checks; SPEC-SEC с STRIDE coverage
A.12.1.2 Change management (наследие 27001:2013)Delta-ТЗ процесс + Impact Analysis (§7.6)

2.2 Audit deliverable

Для ISO 27001 аудита auto-generates conformance report: scope (BR/SR/TC counts с compliance.iso27001 metadata) + Coverage by Annex A (control ↔ mapped SR ↔ status verified/approved/pending). См. §11 — список всех auto-generated артефактов. Substrate-specific команда — informative; нормативный механизм — capability V4 reporting from versioned artifacts.

3. GDPR (Regulation EU 2016/679)

3.1 Mapping articles

GDPR ArticleRENAR-артефакт
Art.5 PrinciplesBR должен явно указывать lawful basis
Art.6 LawfulnessBR с gdpr.lawful-basis: consent / contract / legal-obligation / vital-interests / public-task / legitimate-interests
Art.7 Conditions for consentSR с consent management workflow
Art.13 Information to data subjectSPEC-UI с privacy notice экраном
Art.15 Right of accessSR с export-user-data функциональностью
Art.16 Right to rectificationSR с edit-user-profile
Art.17 Right to erasureSR с delete-user-data + propagation на linked entities
Art.18 Right to restrictionSR с suspend-processing
Art.20 Right to data portabilitySR с export в machine-readable формате
Art.25 Data protection by design and by defaultdata-classification обязателен на BR-уровне
Art.30 Records of processing activitiesAuto-generated из BR с data-classification.contains-pii
Art.32 Security of processingSR с encryption + access control
Art.33 Notification of personal data breachSR с breach notification workflow + 72h timer
Art.35 Data Protection Impact Assessment (DPIA)Для high-risk processing — отдельный dpia/<feature>.md

3.2 GDPR frontmatter

gdpr:
  data-categories:
    - "identification: email, name"
    - "contact: phone, address"
    - "behavioral: usage logs"
  lawful-basis: contract              # Art.6
  retention-period-days: 1095
  cross-border-transfer: false        # если true → обязательны SCCs или adequacy decision
  dpia-required: false                # если true → link на DPIA
  data-subject-rights:
    - access            # Art.15
    - rectification     # Art.16
    - erasure           # Art.17
    - portability       # Art.20

3.3 DPIA как RENAR-артефакт

Для high-risk processing создаётся <system>.req/dpia/DPIA-NN-<slug>.md с frontmatter id / type: DPIA / status / gdpr-article: 35 / related-br[] / risks-identified / mitigations и секциями: Описание процесса обработки, Необходимость и пропорциональность, Риски для прав и свобод субъектов, Меры снижения рисков, Согласование с DPO.

4. ФЗ-152 «О персональных данных» (РФ)

4.1 Mapping статей

ФЗ-152 СтатьяRENAR-артефакт
ст.5 Принципы обработкиBR с явным целевым назначением (поле business-context.business-goal)
ст.6 Условия обработкиBR с lawful-basis
ст.9 Согласие на обработкуSR с consent management
ст.13.1 Хранение в РФdata-classification.data-residency: ["RU"] для российских клиентов
ст.14 Доступ к информацииSR с export-user-data
ст.15 Право на уточнениеSR с edit-user-profile
ст.16 УдалениеSR с delete-user-data
ст.18 Обязанности оператораAudit trail через RENAR traceability
ст.18.1 Локализация ПДн граждан РФdata-classification.data-residency обязательно
ст.19 Меры защитыSR с encryption + access control + ISO 25010 Security
ст.21 Уведомление о нарушенииSR с breach notification workflow
ст.22 Уведомление РКН(operational, вне scope RENAR)

4.2 Особенность: data residency

Для проектов с российскими клиентами data-residency — обязательное поле в data-classification. Substrate hook (capability V6) проверяет:

  • При data-residency: ["RU"] — все upstream SR (хранение, бэкапы, репликация) должны иметь evidence хранения в РФ.
  • При добавлении хранения в зарубежной юрисдикции для RU-резидентного BR — блок integration (требование останавливается на QG-0).

5. EU AI Act (Regulation EU 2024/1689)

5.1 Risk classification

AI Act EU классифицирует AI-системы по уровню риска. RENAR обязывает явно указывать класс:

ai-act:
  risk-class: limited                 # prohibited | high | limited | minimal
  rationale: "Generative AI for document drafting; no autonomous decisions affecting users' legal rights"
  high-risk-domain: false             # если true → требуется conformity assessment
  general-purpose-ai: true            # GPAI — базовая модель (Claude / GPT)

5.2 High-risk AI requirements (Art.9-15)

Для AI-систем класса high (financial scoring, hiring, public services, медицинская диагностика):

AI Act требованиеRENAR-артефакт
Art.9 Risk management systemSPEC-AI + AI risk register (reference/03-ai-risk-register.md)
Art.10 Data and data governanceeval-datasets/ с provenance + spot-check
Art.11 Technical documentationSPEC-AI + ISO/IEC 5338 conformance (см. §7)
Art.12 Record-keepingtool_event audit + ai-provenance во frontmatter
Art.13 Transparency to usersSPEC-UI с обозначением AI-обработки
Art.14 Human oversightOne-click approval + spot-check на QG-0 / QG-2
Art.15 Accuracy, robustness, cybersecurityEval-tests (tc-type: eval) + adversarial review

5.3 GPAI обязательства (Art.51-55)

Если в проекте используется General-Purpose AI Model (Claude, GPT, Gemini и др.):

  • ai-provenance во frontmatter любого AI-сгенерированного артефакта (model id, version, prompt hash).
  • Технический документ модели (если GPAI с systemic risk) — внешний документ + reference из SPEC-AI.

6. NIST AI RMF 1.0 (US-юрисдикция)

6.1 Mapping функций RMF

NIST AI RMF FunctionRENAR-механизм
GovernRENAR сам + роли из SENAR + compliance frontmatter
MapBR с business-context, data-classification, ai-act risk-class
MeasureEval-тесты с metric thresholds + RENAR-метрики (Hallucination Rate, Coverage Velocity)
ManageLifecycle с QG + reconciliation hook + AI risk register

6.2 RMF-специфичные расширения

nist-ai-rmf:
  applicable: true
  govern: { role: "AI Governance Lead", policy-link: "..." }
  map:
    use-case-category: "content-generation"
    affected-stakeholders: ["clients", "internal-team"]
  measure:
    metrics-tracked: ["accuracy", "fairness", "robustness"]
    baseline-run-id: "eval-2026-04-01"
  manage:
    risk-tolerance: "low"
    incident-response-plan: "<link>"

6.3 Когда применять

Опциональное расширение — required только для проектов с US-юрисдикцией клиентов. Не противоречит ISO/IEC 23894 (см. §7); может применяться совместно.

7. ISO/IEC 23894:2023 — AI Risk Management

ISO/IEC 23894 — guidance по AI risk management. Не сертифицирует, но даёт structured framework для управления рисками AI-систем. Совместим с NIST AI RMF и AI Act EU.

7.1 Mapping на RENAR

ISO/IEC 23894 разделRENAR-артефакт
§6.4.1 Risk identificationAI risk register (reference/03-ai-risk-register.md)
§6.4.2 Risk analysisSPEC-AI с risk assessment секцией
§6.4.3 Risk evaluationThreshold для каждого риска в eval-tests
§6.4.4 Risk treatmentSR-mitigations + post-mitigation evaluation
§6.4.5 Communication and consultationRACI matrix (см. 05-safe-comparison.md §9)
§6.4.6 Monitoring and reviewCapability V6 (drift detection) + reconciliation hook

7.2 Что важно для ISO/IEC 23894 conformance

  • Каждый AI-сгенерированный артефакт имеет ai-provenance.
  • Для каждой AI use-case в SPEC-AI задокументированы:
    • Identified risks (минимум: hallucination, bias, robustness).
    • Mitigations (eval thresholds, adversarial review, human-in-the-loop).
    • Residual risks (что осталось после mitigation).
  • Risk register обновляется при изменении SPEC-AI (capability V6 ловит drift).

8. ISO/IEC 5338:2023 — AI System Life Cycle Processes

ISO/IEC 5338 описывает life cycle процессы для AI-систем (extension к ISO/IEC/IEEE 12207). Удобный фреймворк для AI Act Art.11 technical documentation.

8.1 Mapping процессов на RENAR этапы

ISO/IEC 5338 processRENAR-этап
Stakeholder needs and requirements definitionТЗ + ADAPT + BR
Architecture definitionSPEC-ARCH + SPEC-AI
Design definitionSPEC-AI (model card, prompt design, RAG)
ImplementationTR + реализация
VerificationTC (tc-type: eval для AI)
ValidationAcceptance TC + spot-check
OperationCapability V6 (drift detection) + reconciliation
MaintenanceDelta-ТЗ + ADAPT iteration
DisposalRetirement workflow для AI-моделей (вне scope Core RENAR)

8.2 Conformance evidence

RENAR покрывает ISO/IEC 5338 если:

  • SPEC-AI существует для каждой AI use-case с полной model card.
  • Eval-tests привязаны к SPEC-AI через verifies[].
  • ai-provenance зафиксирован для всех AI-сгенерированных артефактов.
  • Drift detection активен (capability V6).

9. PCI-DSS v4.0 — Payment Card Industry Data Security Standard

Если проект обрабатывает данные платёжных карт (cardholder data, CHD):

9.1 Mapping PCI-DSS requirements

PCI-DSS v4 requirementRENAR-артефакт
Req.1 Network security controlsSPEC-OPS с network segmentation
Req.3 Protect stored CHDdata-classification.contains-financial: true + SR с encryption-at-rest
Req.4 Encrypt CHD transmissionSR с TLS + SPEC-API requirements
Req.6 Develop secure systemsRENAR + SENAR как process compliance evidence
Req.7 Restrict access by need to knowSR с RBAC + SPEC-SEC access control matrix
Req.8 Authenticate accessSR-AUTH-* + MFA где обязательно
Req.10 Log and monitor accessSR с audit log + SPEC-OPS observability
Req.11 Test security regularlyTC tc-type: security + pen-test (вне RENAR scope)
Req.12 Information security policyRENAR + SENAR как documented policy

9.2 Особенность: CHD scope minimization

PCI-DSS требует минимизации scope CHD storage. Substrate hook (capability V6) проверяет, что новые SR с contains-financial: true явно обосновывают необходимость хранения CHD — без обоснования требование останавливается на QG-0.

10. Self-assessment checklists

Короткие yes/no checklists для compliance teams. Один проход — оценка готовности к аудиту.

#FrameworkКлючевые проверки (всё [ ])
10.1ISO 27001:2022Все BR с contains-pii: true имеют SR закрывающий A.5.34 / SoA задокументирован / каждый in-scope control имеет ≥ 1 verifying SR / coverage report зелёный для compliance-tagged SR / аудитор может пройти от control до passing TC за < 5 минут
10.2GDPRВсе обработки PII в Records of Processing (auto) / lawful basis указан / data subject rights Art.15-22 verifiable / DPIA выполнен для high-risk / cross-border transfers обоснованы (SCCs или adequacy)
10.3ФЗ-152Все требования с PII граждан РФ имеют data-residency: ["RU"] / substrate hook проверяет upstream SR хранения / согласие реализовано в SR / меры защиты ст.19 покрыты SR с TC
10.4EU AI ActКаждый SPEC-AI имеет ai-act.risk-class / для high выполнено Art.9-15 / human oversight на QG-0/QG-2 + spot-check / technical documentation auto-generated / ai-provenance для GPAI
10.5NIST AI RMFВсе 4 функции (Govern/Map/Measure/Manage) имеют evidence / AI Governance Lead определён / eval baseline зафиксирован / incident response plan связан со SPEC-AI
10.6ISO/IEC 23894AI risk register заполнен и связан со SPEC-AI / каждый риск имеет mitigation в SR / residual risks accepted владельцем / V6 активна
10.7ISO/IEC 5338SPEC-AI существует для каждой AI use-case с model card / eval-tests привязаны через verifies[] / ai-provenance зафиксирован / V6 активна
10.8PCI-DSSВсе SR с contains-financial: true имеют encryption-at-rest и encryption-in-transit / CHD scope минимизирован / RBAC в SPEC-SEC / audit log SR покрывает все CHD-touching / security TC прогоняются регулярно

11. Auto-generated compliance artifacts

RENAR предлагает генерируемые из существующих требований артефакты для аудиторов:

ArtifactИсточникСодержание
Records of Processing (GDPR Art.30)BR/SR с data-classification.contains-pii: trueКатегории данных, lawful basis, retention, recipients
Statement of Applicability (ISO 27001)BR/SR с compliance: ISO 27001:2022Какие Annex A controls в/вне scope, justification
Data InventoryВсе data-classification записиCategories, residency, retention, owners
AI System CardsSPEC-AIModel card по NIST AI RMF / AI Act format
Audit Trail ReportTraceability BR → SR → SPEC → TC → last-runПолная цепочка от control до prooof-of-verification
DPIA Indexdpia/ папкаСписок DPIA + статус согласования с DPO
AI Risk Register SnapshotAI risk registerВсе идентифицированные риски + mitigations + residual

Substrate-specific команда (informative пример): tausik renar compliance-report --standard <name> --project <slug>. Нормативный механизм — capability V4 (reporting from versioned artifacts).

12. Что RENAR НЕ покрывает в compliance

RENAR — инфраструктура для compliance, но не substitute для:

  • DPO (Data Protection Officer) — человеческая роль, юридическая ответственность.
  • Legal review договоров и privacy notices.
  • Pen-testing имплементации (отдельный security workflow).
  • Bug bounty / vulnerability management (operational).
  • Physical security (датацентры, офис).
  • Operational security — key rotation, incident response, monitoring runbook.
  • Cyber insurance.
  • Regulatory filings — уведомления РКН, GDPR registration с DPA, AI Act conformity assessment.

RENAR помогает делать compliance в процессе разработки требований. Operational compliance — отдельные процессы, которые могут ссылаться на RENAR-артефакты как на evidence.

13. Open questions

Не закрыты в этой главе и подлежат уточнению:

  • Compliance frontmatter — обязательный или optional? Compromise: optional, но при data-classification.contains-pii: true → обязательным становится compliance с GDPR / ФЗ-152.
  • DPIA как RENAR-артефакт vs внешний документ? Mixed: формальный DPIA → внешний (юристы), dpia/<slug>.md ссылается на него и трассируется.
  • Data residency: как enforced на уровне инфры? Cross-check на deployment configs — это уже DevOps зона.
  • Custom compliance frameworks (отраслевые — ЦБ РФ для финтех, HIPAA для healthcare): добавлять в этот документ или отдельный?
  • Schrems II adequacy для EU↔RF transfers: можно ли через RENAR автоматически генерировать evidence? Частично — через cross-border-transfer flag + SCCs ref.

См. также research/09-compliance-mapping.md — исследовательский draft.

14. Связь с другими главами