Cursor Rules Template: GDPR Risk Assessment Tools from Website Forms and Data Flows

Overview

Direct answer: This Cursor rules template provides a complete, copyable .cursorrules block and stack-specific guidance to build GDPR risk assessment tools using website forms and data flows with Cursor AI. It targets a Node.js/Express backend with PostgreSQL and TypeORM, including privacy-by-design controls, consent checks, and auditable data lineage.

When to Use These Cursor Rules

• You're building a GDPR risk scoring or risk assessment tool that ingests form data and data-flow information.
• You need enforceable privacy controls in forms, API, and storage layers.
• You require consistent coding standards and secure authentication patterns.

Copyable .cursorrules Configuration

# Cursor Rules Template for GDPR Risk Assessment
# Framework Role & Context
role: Backend Engineer
framework: Node.js/Express
context: GDPR risk assessment from website forms and data flows

# Code Style and Style Guides
lintTool: eslint
formatter: prettier
language: typescript
strict: true

# Architecture & Directory Rules
architecture:
  - src/
  - src/controllers/
  - src/routes/
  - src/services/
  - src/models/
  - src/middlewares/
  - src/config/
  - src/migrations/
  - tests/

# Authentication & Security Rules
security:
  - auth: JWT with RS256
  - csrfProtection: true
  - rateLimiting: true
  - dataMinimization: true
  - piiHandling: inFormOnly

# Database and ORM patterns
db:
  orm: TypeORM
  provider: postgres
  dbName: gdpr_risk
  entities: src/models/**/*.ts
  migrations: src/migrations/*.ts
  schemaSync: false

# Testing & Linting Workflows
testing:
  unit: jest
  integration: supertest
  e2e: cypress

# Prohibited Actions and Anti-patterns for the AI
anti:
  - avoid logging PII
  - do not bypass server-side validation
  - do not expose raw DB queries to client
  - no client-side crypto for PII
# Cursor AI rules
cursor_ai_rules:
  - ensure GDPR checks for consent before processing
  - trace data lineage from forms to storage
  - enforce data minimization and retention policies

Recommended Project Structure

gdpr-risk-assessment-tool/
├── src/
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   ├── services/
│   ├── middlewares/
│   ├── config/
│   └── migrations/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
├── .eslintrc.js
├── tsconfig.json
├── package.json

Core Engineering Principles

• Privacy by design: build with consent, minimization, and purpose limitation at every layer.
• Security first: enforce authentication, authorization, auditing, and encryption.
• Data flow visibility: end-to-end tracing from form submission to storage.
• Strong typing and validation: use DTOs and runtime checks for all inputs.
• Deterministic builds and tests: stable CI/CD with reproducible environments.

Code Construction Rules

• Use TypeORM entities in src/models and migrations for schema evolution.
• Validate inputs with DTOs and runtime schemas; reject invalid data early.
• Keep business logic in services; keep controllers thin and by-the-book.
• Respect data minimization in every API and data store operation.
• Write modular, testable code with clear interfaces and dependency injection where possible.

Security and Production Rules

• Store secrets securely; never hard-code credentials; use environment variables and secret managers.
• Enable TLS in all endpoints; enforce strict transport security and CORS policies.
• Implement robust authentication (JWT RS256) and per-endpoint authorization checks.
• Encrypt sensitive fields at rest where feasible and enforce proper data retention policies.
• Set up immutable audit logs and tamper-evident records for risk assessments.

Testing Checklist

• Unit tests for validators, services, and data transformations.
• Integration tests for API endpoints with realistic data flows.
• End-to-end tests simulating form submissions and GDPR consent flows.
• Static analysis and linting in CI; run tests on each PR.

Common Mistakes to Avoid

• Storing PII in logs or in plaintext databases without encryption.
• Skipping server-side validation or relying on client-side checks only.
• Ignoring data retention schedules or consent revocation in workflows.
• Leaking internal DB queries or schema details through API responses.

Related implementation resources: AI Agent Use Case for Saas SMEs Using Churn Signals to Identify Customers Likely to Cancel and Compliance testing for high-risk AI: governance, validation, and production readiness.

FAQ

What is a Cursor rules template for GDPR risk assessment?

A Cursor rules template provides a complete, copyable .cursorrules block and stack-specific guidance to build GDPR risk assessment tooling that analyzes website forms and data flows, enforces privacy-by-design, and logs auditable outcomes.

Which stack is this template configured for?

The template targets a Node.js with Express backend, PostgreSQL database managed via TypeORM, and Cursor AI for rule-driven scaffolding and governance.

How do I integrate with website forms and data flows?

The rules emphasize form validation, consent capture, data minimization, and end-to-end tracing from form submission to storage, enabling GDPR risk scoring and reporting.

What should I implement for auditing and security?

Include immutable audit logs, JWT-based authentication, CSRF protection, rate limiting, and encryption of sensitive fields both in transit and at rest.

Where do I paste the .cursorrules file?

Place the copied .cursorrules block in the project root as .cursorrules, then Cursor AI will guide code generation and enforcement per the template.