GRC — Interview Prep

Policy is the "what and why" — high-level management intent, mandatory at an organizational level. Example: "Ficsit Inc. will protect the confidentiality, integrity, and availability of customer data." Policies don't tell anyone how to do anything specific.

Standard is a specific, mandatory requirement that operationalizes the policy. Example: "All user passwords must be at least 14 characters and include at least one uppercase letter, one number, and one special character." Standards are testable and auditable.

Procedure is the step-by-step "how" — what someone actually does to comply with the standard. Example: a password reset procedure with numbered steps for the helpdesk.

Guideline is recommended but not mandatory best practice — advisory content for when the standard doesn't dictate a specific approach. Example: "When choosing a passphrase, consider using three or more unrelated words."

The hierarchy flows: Policy → Standard → Procedure, with Guidelines as supporting reference at any level.

The NIST Cybersecurity Framework (CSF) is a voluntary framework for managing cybersecurity risk, widely adopted across industries in the US and internationally. CSF 2.0 (released 2024) is the current version.

It's organized around six Functions: Govern (new in 2.0 — policies, roles, risk strategy), Identify (understand your assets, risks, and environment), Protect (implement safeguards), Detect (identify security events), Respond (contain and analyze), Recover (restore capabilities).

Under each Function are Categories and Subcategories — specific security outcomes to achieve. The framework is intentionally technology-neutral and scalable to any organization size. It maps to ISO 27001, CIS Controls, and other frameworks, making it a useful translation layer between different compliance requirements.

A risk assessment identifies, evaluates, and prioritizes risks. It answers: what could go wrong, how likely is it, and what would the impact be? The output is a risk register — a documented inventory of risks with likelihood and impact ratings.

Risk treatment is the decision about what to do about each identified risk. Four options:

Accept: The risk is within the organization's risk tolerance — it costs more to mitigate than the expected loss. Document the decision and owner.

Mitigate: Implement controls to reduce likelihood or impact below acceptable threshold.

Transfer: Shift the financial risk to a third party via insurance or contractual liability.

Avoid: Stop doing the activity that creates the risk entirely.

Assessment comes first; treatment is the response. Organizations revisit both periodically and whenever the environment changes significantly.

SOC 2 is an auditing standard developed by the AICPA for service organizations — primarily SaaS companies and cloud providers — that defines how they protect customer data. It's based on the Trust Services Criteria.

Five Trust Services Criteria: Security (always required, also called "Common Criteria"), Availability, Processing Integrity, Confidentiality, and Privacy. Organizations choose which criteria to include beyond the mandatory Security category.

Two types: Type I is a point-in-time assessment — auditor confirms controls exist as of a specific date. Type II covers a period (typically 12 months) and attests that controls operated effectively throughout — significantly more rigorous and valuable.

Enterprise customers care because it provides independent third-party assurance that a vendor has real security controls, without the customer needing to audit the vendor themselves. Many enterprise procurement and legal teams make a current SOC 2 Type II report a contractual requirement before signing.

SOC 2 is a US-developed attestation framework — an independent auditor issues a report stating whether your controls meet the AICPA's Trust Services Criteria. It's report-based, not certificate-based. Common in North American enterprise sales contexts.

ISO 27001 is an international standard for an Information Security Management System (ISMS) — you receive a certificate after demonstrating that you've implemented a systematic, risk-based approach to managing information security. Required by many European customers and in global enterprise sales outside North America.

Key differences: ISO 27001 is a certification with a formal certificate; SOC 2 produces a report. ISO 27001 is process-focused (how you manage security); SOC 2 is control-focused (are specific controls in place). The underlying control sets largely overlap, which is why many organizations pursue both simultaneously using shared evidence.

Don't say "no" — say "here's what you're accepting." GRC operates without direct authority over business teams, so your influence comes from making the risk explicit and putting it in the right person's hands.

First, quantify or characterize the risk in business terms: "Launching without this review means we're accepting unknown exposure on the payment flow, which is subject to PCI. If there's a breach, the notification and fine costs would significantly exceed the cost of a 3-day security review."

Offer a faster path: a risk-ranked abbreviated review that covers the highest-impact areas in a compressed timeline. Reduce friction — most teams want to get to launch, not skip security.

If they choose to proceed anyway: document the risk in writing, get a formal risk acceptance sign-off from the appropriate business owner (not you), and escalate to your manager if the risk is material. Your job is to make the risk clear and ensure the right people own the decision — not to be the blocker.

Translate to business language immediately. Not: "We have a CVSS 9.8 vulnerability in our payment processing stack." Instead: "A critical flaw in our payment system could allow an attacker to access all customer payment card data — that's a mandatory PCI breach notification, potential card brand fines starting at $5,000-100,000 per month, and customer churn risk."

Use the financial framing they already understand: expected loss (probability × impact), cost of control vs. cost of breach, and industry comparables if available ("The average cost of a data breach in our sector is $X per the IBM report").

Close with a specific ask — not just "we have a risk" but "we need $X or 2 sprints of engineering time to fix this. Without it, we're accepting this risk until Q3." Give them a decision, not a briefing.

One page max for written. Five minutes for verbal.

Plan and communicate early. Give control owners a specific, itemized list of what's needed, in what format, and by what date — with enough lead time to avoid a fire drill. Vague requests ("we need security evidence") cause more disruption than specific ones.

Build a central evidence repository with a tracking dashboard so you and the auditors can see status without a daily status call. Assign clear owners to each control area.

Prioritize high-risk control areas first — if a critical control takes longer to gather evidence for, you want to know early, not during the final audit week.

Build relationships with control owners before audit season. If the first time you contact someone is when you need their evidence immediately, the relationship will be adversarial. Ongoing communication makes them responsive when you actually need something fast.

Escalate through proper channels immediately. Inform your manager and the business unit's leader. This isn't about blocking the launch — it's about ensuring the right people know the risk before launch, not after.

Offer a fast-path review. Propose a 2-3 day rapid assessment focused on the highest-risk elements: data classification (what data does the product handle?), authentication and authorization design, third-party integrations, and data flow to/from external systems. You can't do a full review in a week, but you can cover the critical risks.

Document the risk formally regardless of outcome. If the business unit chooses to launch without a full review, get a formal risk acceptance signed by the appropriate business owner — not a verbal "it's fine." This protects the security team and puts accountability where it belongs.

If the product handles sensitive data or has regulatory implications (PCI, HIPAA, GDPR), escalate to legal and compliance as well. They may have mandatory obligations that supersede the business unit's preference to ship.

Escalate to vendor management and legal — vendor security obligations are typically contractual, not optional. If the vendor is under an agreement that includes security disclosure requirements, non-compliance is a contract issue.

Assess materiality first. Does this vendor handle sensitive data, have network access to your environment, or process payments? Higher risk = higher urgency to resolve this, and potentially a reason to delay or pause use of the vendor.

Request alternative evidence: ISO 27001 certificate, penetration test executive summary, a reference customer who can speak to their security posture, or a third-party security rating (SecurityScorecard, BitSight). An alternative isn't as good as a SOC 2 but it's something.

If the vendor won't engage at all, document this as an unresolved risk and bring it to the business owner who wants to use the vendor. They need to understand they're proposing to use a vendor whose security posture is unknown. The decision is theirs, but the documented risk is yours to present clearly.