Security Operations Basics for GRC

Brief

At Alder Quay Services, a customer portal outage exposes confused control ownership. A transferred employee still has administrator access, an urgent firewall change has no approval record, and a vulnerability ticket was closed because a patch was scheduled. The operations manager calls every alert an incident and offers a dashboard screenshot as proof that all controls work.

You are the GRC analyst preparing an evidence sample. Your job is not to run the response team: it is to distinguish the processes, explain their decision points, and trace claims to dated records. The company policies and deadlines below are teaching examples, not universal legal or framework requirements.

A policy proves intended practice. A linked request, decision, execution record, and verification result show whether that practice actually operated.

Access is a lifecycle, not a login

Provisioning creates an account and assigns authorized entitlements after a verified request. Authentication establishes who is signing in; authorization determines what that identity may do. Least privilege limits permissions to the minimum needed for the role and duration. A successful login proves neither business need nor approval. Separate ordinary and privileged identities, require strong authentication, and avoid shared accounts that prevent attribution.

Use joiner, mover, and leaver triggers. At Alder Quay, a new invoice analyst receives read access to invoices, not payment-release rights. A move to customer support removes invoice permissions before adding the new role; simply adding the second role accumulates privilege. The example policy requires leaver access disabled within 4 hours of the effective termination time and production access reviewed every 90 days. A review of 80 accounts identifies 6 inappropriate grants: the review is not complete until removals or approved exceptions are verified.

Retain the request, manager and resource-owner approvals, entitlement scope, provisioning timestamp, and system-generated assignment record. For a review, retain the population as of a stated date, reviewer identity, individual decisions, remediation tickets, and removal verification. An auditor asks whether the population includes service and privileged accounts and whether rejected access actually disappeared. A signed spreadsheet without follow-through is evidence of a decision, not proof of revocation.

Change categories describe authorization paths

A normal change follows risk assessment, testing, an implementation and rollback plan, and approval before execution. A standard change is a repeatable, low-risk procedure already assessed and preauthorized within defined conditions. It still needs an execution record and must stay within its approved scope. A change is not standard merely because it happens often or uses a familiar command.

An emergency change addresses an urgent threat or major service impact through an expedited authorization path. Alder Quay requires a designated emergency approver before execution and retrospective review within 2 business days. For example, blocking an actively exploited portal endpoint may qualify; a forgotten routine renewal does not automatically qualify. If immediate life-safety action makes prior approval impossible, document the extraordinary deviation and accountable decision rather than inventing an approval timestamp afterward.

An auditor samples the change identifier, category rationale, risk assessment, test results, author and approver identities, approval timestamp, exact implementation scope, execution logs, rollback readiness, and post-change checks. A normal change approved at 10:30 but executed at 10:00 failed the preapproval requirement. Emergency review is additional oversight, not a substitute for this example policy's emergency authorization. Separation of author and approver reduces self-authorization; a successful deployment alone proves neither authorization nor adequate testing.

Vulnerabilities need a clock and a closure test

Vulnerability scanning identifies suspected weaknesses; it does not prove exploitation or prove coverage of every asset. Reconcile scan targets to inventory, check credentialed scan success, validate suspected false positives, and assign an accountable owner. For CVSS v3.1, the base severity bands are none at 0.0, low at 0.1-3.9, medium at 4.0-6.9, high at 7.0-8.9, and critical at 9.0-10.0. Record the score version and vector: technical severity is not the same as business risk or incident severity.

Alder Quay's example remediation SLAs run from first confirmed detection in calendar days: critical 7, high 30, medium 90, low 180. A high finding confirmed on 1 April at 09:00 is due on 1 May at 09:00; rescanning does not restart the clock. A CVSS 8.1 issue on an isolated test host and the same issue on an exposed customer portal share a base severity, but exposure and active exploitation may justify accelerating the portal's response. A planned patch is not remediation; close only after a targeted rescan or equivalent documented verification confirms the weakness is removed.

An exception records the affected assets and finding, rationale, residual risk, compensating controls, accountable risk-owner approval, expiry, and review date. It does not erase the original detection date or mark the weakness fixed. For example, a high finding due on 1 May may have an approved exception through 15 May with network isolation and weekly checks; report it as open under exception. Auditors ask for inventory reconciliation, scan configuration and results, dated tickets, SLA calculations, exception decisions, and verification evidence, including overdue items rather than only successes.

An event becomes an incident through assessment

An event is an observable occurrence such as a failed login. An alert is a notification generated by a detection rule. An incident is an assessed occurrence that actually or imminently jeopardizes security or violates security policy. Ten failed logins may be harmless user error; a confirmed unauthorized privileged session is an incident even if only one alert exists. A vulnerability describes a weakness, not proof that someone used it.

Define incident severity by impact, scope, urgency, and confidence, not by the CVSS score of a suspected entry point. In Alder Quay's example, severity 1 means confirmed customer-data exfiltration or widespread critical-service loss; severity 2 means a contained compromise without those impacts. Both require response. A suspected export starts under a provisional severity and is revised as evidence develops. Capture the basis and time of each revision so a later downgrade does not conceal the initial response obligation.

Prepare roles and playbooks, detect and analyze, contain, eradicate, recover, and perform lessons learned. Containment limits damage, such as isolating a host; eradication removes the cause, such as malicious persistence; recovery restores and validates safe service. Preserve evidence alongside urgent response, recording collection times, hashes when appropriate, transfers, and authorized handlers. Auditors request the incident timeline, classification decisions, containment actions, communications and notification assessments, recovery checks, and tracked corrective actions. Restoring service is not the same as completing the investigation.

Logs are raw material; monitoring is a working process

Logging records activity; monitoring collects and evaluates it for conditions requiring action. Useful records identify actor, action, target, outcome, source, and a timestamp with timezone. Synchronize clocks so an access grant at 09:02 can be correlated with a change at 09:05. Central collection reduces dependence on a potentially compromised host, but a collector receiving data is not proof that anyone investigates alerts.

Alder Quay requires 90 days of searchable authentication and privileged-action logs and 365 days of protected archive retention. These are example policy values, not automatic compliance with every law. Restrict readers and deletion rights, protect integrity, and avoid recording passwords or unnecessary personal data. If 2 of 20 production servers stop sending logs, the coverage gap is 10%; a quiet dashboard could reflect lost visibility rather than a safe environment. Alert on missing sources as well as suspicious activity, route notifications to an owner, and test end-to-end response.

Auditors ask for the expected source inventory, collection-health reports, retention configuration and retrieval tests, clock synchronization settings, access permissions, detection rules, and sampled alert dispositions. A test that generates a failed privileged login should link the source record, triggered alert, notification receipt, triage decision, and any incident ticket. An installed agent proves installation; a dated chain proves that a specific detection path operated.

Build an audit trail across process boundaries

Use stable identifiers to link related processes without collapsing their purposes. Finding V-24 may require patch change C-18; execution of C-18 leads to verification scan S-09. If investigation establishes compromise, incident I-07 references those records and the relevant access and log evidence. The vulnerability ticket does not replace change approval, and an approved change does not close an incident automatically.

Suppose a quarterly sample includes 12 access removals and 10 high vulnerabilities. Eleven removals met the 4-hour leaver requirement and one took 7 hours: report 11 of 12 timely, not universal compliance. Eight vulnerabilities were verified fixed within 30 days, one remains open under an approved exception, and one is overdue without approval: report those three populations separately, rather than claiming 9 of 10 remediated. Keep denominators, time windows, exclusions, and evidence extraction dates visible.

Evidence should demonstrate who acted, on what scope, under whose authority, when, and with what verified result. Preserve source exports with extraction methods, link approvals to the specific object and version, and control access and retention. An auditor distinguishes control design from operating effectiveness: a complete procedure describes the design, while a representative set of reliable execution records shows operation. Missing evidence may mean an unproven control rather than proven wrongdoing, but it still requires investigation and an honest limitation in the assurance conclusion.

Answers are graded on the server: the answer key never reaches your browser.