heygrc and Cursor Security

Different jobs, same pull request.

Cursor's security agents and heygrc both look at your changes, but they ask different questions. The security agents ask whether the code is safe: is there a vulnerability, an unsafe pattern, a risky change. heygrc asks whether a change touches a compliance control your company has to meet, and cites the framework clause it lands on.

Security and compliance overlap, but they are not the same. Whether a change is safe and whether it moves a compliance control are separate questions, because the obligation lives in your framework rather than in the code.

Install on GitHub by ISMS Copilot

Cursor Security

Cursor's security agents review your code for security problems: they check pull requests for vulnerabilities and can scan a codebase for security issues.

heygrc

heygrc reviews each pull request against the compliance frameworks your company must meet (ISO 27001, SOC 2, GDPR, and more) and cites the specific control a change touches. It is built for compliance, not code quality.

Where they do not overlap

Code that starts collecting new personal data.

This change starts saving each user's precise location with every event, to power a new map view. Assume the code is well-formed: the value is validated and stored like any other field. The company is now processing a new category of personal data that its records of processing and privacy notice never mentioned.

events/track.ts+1 −0

export async function track(event: AppEvent, user: User) {  const row = { type: event.type, userId: user.id, at: Date.now() }  row.location = event.coords // precise GPS lat/lng  await events.insert(row)}

heygrcGDPR Art. 30

The change starts processing a new category of personal data, the user's precise location. Nothing about the code has to be unsafe for this to matter: the records of processing under GDPR Art. 30 no longer match what the system collects, and the privacy notice built on them (GDPR Art. 13) needs the same update. heygrc is built to catch exactly this, a change that shifts what you process and what you must document.

Use them together

Keep Cursor Security. Add the compliance layer.

This is not a question of which tool wins. Cursor Security catches the bugs and quality problems heygrc never looks for, and heygrc catches the compliance issues a code review is not built to see. Running both means a pull request is checked for whether the code is good and for whether the change is compliant, two different kinds of risk, on the same diff.

heygrc does not replace your code review, and it does not certify you. It reviews changes against your frameworks and cites the control, so the compliance question is answered where the change is made.

Install on GitHub ← Where heygrc fits

Questions

heygrc and Cursor Security, common questions.

Is heygrc an alternative to Cursor Security?

Not exactly. Cursor Security reviews your code; heygrc reviews each change for compliance against the frameworks your company must meet (ISO 27001, SOC 2, GDPR, and more) and cites the specific control it touches. They answer different questions about the same pull request, so heygrc is designed to run alongside it, not replace it.

Can I use heygrc and Cursor Security together?

Yes. They look at different kinds of risk on the same diff: Cursor Security on the code, heygrc on the compliance control a change touches. heygrc does not replace your code review.

What does heygrc check on a pull request?

heygrc reviews each pull request against the frameworks your company selected and cites the specific control a change touches, so the compliance question is answered in code review. heygrc does not certify you.