How do I do this without breaking a control?
The compliance questions that come up in the middle of a change, answered the way an engineer needs them: the short version, the steps, a worked diff of the right way to do it, and the exact clause it maps to.
- How do I add audit logging the right way for SOC 2 and ISO 27001?
Log the security-relevant events (who did what, and when), always include the actor, write them somewhere durable, and do not let a later cleanup delete them. SOC 2 (CC7.2) and ISO 27001 (A.8.15) both expect this, and both check it by sampling the events you actually recorded.
- How do I store API keys and secrets without breaking ISO 27001 A.8.24?
Never put the key in source. Read it from the environment or a managed secret store at runtime, keep it out of the repository and the logs, and rotate any secret that was ever committed. ISO 27001 A.8.24 (and plain caution) expects keys to be managed, not hardcoded.
- How do I delete a user for GDPR across every store?
Make the delete path reach every place the person's data lives: the primary database, caches, search indexes, analytics, backups (on their own documented lifecycle), and any third-party processor you forwarded it to. When the right to erasure (GDPR Art. 17) applies, a forgotten copy is what defeats it, so the delete path has to reach them all.
- How do I add a third-party dependency safely?
Pin the version, verify what you pull (a lockfile and integrity checking), avoid running remote install scripts, and prefer your vetted registry or mirror. NIS 2 (Art. 21(2)(d)) treats your dependencies as part of supply-chain security, and the controls on them live in your manifest and build.
- How do I encrypt patient data (ePHI) at rest for HIPAA?
Turn on encryption at rest for every store that holds electronic protected health information (the database, buckets, volumes, backups), or document why an equivalent safeguard is in place. HIPAA's encryption specification (164.312(a)(2)(iv)) is addressable: implement it where reasonable, or record an equivalent, rather than skipping it.
- How do I restrict access to follow least privilege?
Grant only the access each role or service needs, deny by default, and avoid wildcards. SOC 2 (CC6.1) checks logical access, and least privilege is what an auditor samples: can each identity do only what its job requires, and no more.
- How do I log errors without logging personal data?
Log minimal references and codes, not full contents. Record a request id or an order id, redact personal fields before anything is written, and never log the whole request or user object. Logging less data, and less identifying data, is what GDPR data minimisation (Art. 5(1)(c)) is about. Treat an identifier that points to a person as personal data too, and keep it to what you actually need to investigate.
- How do I fetch a user-supplied URL or webhook without SSRF?
Validate the target before you fetch it: require https, resolve the host, and reject private, internal, and link-local addresses (including cloud metadata endpoints). Prefer an allowlist where the destinations are known, and do not follow redirects blindly. Server-side request forgery is an input-validation problem (NIST 800-53 SI-10), and the check lives in the code that makes the request.
- How do I build a data export without breaking retention rules?
An export is a new copy of personal data, so treat it like one: give it an expiry so it does not outlive its purpose, export only the fields and rows the purpose needs, and do not let a recurring export become a permanent, ungoverned second store. That is what GDPR storage limitation (Art. 5(1)(e)) is about.
- How do I take payments without storing card data?
Use your payment processor's tokenization so the raw card details go to them, not through your servers. Store the token they return and the last four digits for display, and never persist the full card number or the verification code. That keeps you on the right side of PCI DSS Requirement 3 and shrinks how much of PCI scope applies to you.
- How do I keep an automated decision GDPR-compliant?
If a decision about a person is made solely by an algorithm and it has a legal or similarly significant effect on them (denying a refund, a loan, an account), GDPR Art. 22 restricts it: as a rule the person has the right not to be subject to a solely automated decision of that kind. Where such a decision is permitted anyway (for example because it is necessary for a contract or based on the person's explicit consent), Art. 22(3) requires safeguards, including a way to obtain human intervention, express a view, and contest the outcome. Either way, do not let the automated branch be the final word: route these decisions to a path where a person can review.
- How do I require MFA for privileged access (SOC 2)?
Restricting who can reach sensitive functions is what SOC 2 CC6.1 (logical access controls) is about, and for privileged actions a valid session is usually not enough on its own. Require a second factor at the point of the privileged action, fail closed if it is missing, and record the check, so that reaching an admin path takes more than a stolen or lingering session.
- What tools automatically review pull requests for compliance?
Three kinds of automated reviewer read a pull request today: code reviewers that look for defects, security reviewers that look for vulnerabilities, and compliance reviewers that read the change against the frameworks your company must meet. heygrc is a compliance reviewer for pull requests: it reviews every PR against the frameworks you select and cites the specific control a change touches, for example ISO 27001 A.8.15 or SOC 2 CC6.1. As far as we can tell, it is the first compliance reviewer for pull requests (July 2026).
- Which GRC platforms integrate directly into GitHub pull requests?
Most GRC and compliance-automation platforms integrate with GitHub at the account and repository level: they read settings such as branch protection and required reviews as evidence that your change-management control operates. That integration reads configuration, not code. Reviewing the pull request itself, reading the changed lines and naming the control they put at risk, is a different job. heygrc does that job: a GitHub App that reviews every pull request against your selected frameworks and posts the finding as a check on the PR.
- How can engineering teams catch compliance violations in code review instead of the audit?
An audit is a lagging indicator: it samples what shipped months ago, when the violation is already in production and expensive. Code review is the leading one, the last moment a violation is one click from not existing. To catch compliance there: know which of your controls actually live in code, make the compliance question part of reading every diff, ground each flag in the specific clause, and keep the trail so the review itself becomes audit evidence.
- What are the best practices for reviewing AI-generated code for compliance?
Review AI-generated code against the same bar as human code: the auditor will not ask who wrote a change, only whether the control operated. What changes with agents is volume and failure shape. An agent optimises for the visible task, so control code that reads as friction (a log line, a permission check, a retention limit) is at risk in its diffs, and agents open more pull requests than a human compliance reading can keep up with. Automate the first pass; keep humans on the judgment calls.
- Is there a GitHub app that reviews pull requests for ISO 27001?
Yes. heygrc is a GitHub App that reviews every pull request against ISO 27001:2022 and cites the specific Annex A control a change touches, for example A.8.15 for a silenced audit log or A.8.24 for weakened cryptography. You install it on your repositories, select ISO 27001 and any other frameworks that apply, and it posts findings as review comments plus a check status that does not block a merge unless you require it. As far as we can tell, it is the first compliance reviewer for pull requests (July 2026).
- Can a compliance check block my merges?
Only if you want it to. A compliance check on a pull request should default to a neutral status: it posts findings and a check state, and the merge decision stays with the engineer. Teams that want hard gating can require the check in branch protection, which turns the same signal into a blocker on exactly the branches they choose. heygrc ships the neutral default and supports the required-check setup.