Security operations foundations: principles and the security operations centre

Security operations is the part of security that never stops. Policies are written once and reviewed yearly; architecture changes over months; but operations happens every hour of every day. Someone has to watch the logs, approve the access requests, apply the patches, rotate the privileged credentials, answer the alarm at two in the morning and restore the system when it fails. Domain 7 of the CISSP outline, Security Operations, is about doing that work well and governing it so that it stays reliable, lawful and accountable.

Domain 7 carries about 13 % of the exam weight under the outline ISC2 introduced on 15 April 2024. ISC2's exam refresh page still listed that outline as current when we checked in October 2026, so confirm the outline on isc2.org before you book. This course is independent study material: it is not produced, endorsed or reviewed by ISC2, and every question in it is original. The domain is broad. It covers investigations and evidence, logging and monitoring, configuration and change management, resource protection, preventive and detective controls, incident management, recovery, business continuity, and physical and personnel security. The CISSP view is consistently that of a manager or senior practitioner: you are expected to know what good operations looks like, how to organize it, what the law requires and how to make sound decisions under pressure, not how to operate a particular product.

This first lesson sets out the foundational operating principles that the rest of the domain relies on: need to know and least privilege, separation of duties, job rotation and mandatory vacations, privileged account management and service level thinking. It then introduces the security operations centre, the team and facility that applies those principles every day, and the different ways organizations staff and source one.

Need to know and least privilege

Least privilege means that every person, process and system receives only the access it needs to perform its function, and no more, for only as long as it needs it. Need to know is the related principle for information: even someone with a clearance or role that would permit access to a category of data should see a particular item only if their work requires it. A payroll analyst may be cleared to see salary data, but need to know limits them to the business units they support.

These principles sound simple and are hard to sustain. Access accumulates as people change roles, a pattern called privilege creep. Project accounts outlive their projects. Emergency access granted during an outage is never removed. Security operations keeps least privilege real through four routine activities: role-based provisioning that grants standard access packages, approval workflows for anything beyond the package, periodic access reviews in which managers recertify what their staff hold, and prompt deprovisioning when people leave or move. The identity mechanics behind these activities are covered in CISSP-114; Domain 7 asks you to run them as reliable operational processes.

A useful extension is just-in-time access. Instead of holding powerful rights permanently, an administrator requests elevation for a defined task and time window, the request is approved and logged, and the rights expire automatically. This shrinks the window in which a stolen credential or a careless action can do damage.

Separation of duties, dual control and two-person integrity

Separation of duties divides a sensitive task so that no single person can complete it alone. The classic financial example separates the person who creates a vendor from the person who approves payments to vendors. In security operations, common separations include: the developer who writes code does not deploy it to production; the administrator who manages the logging platform is not the person whose activity those logs mainly record; the person who requests a firewall change is not the person who approves it.

Dual control is a stronger form: two people must act together, at the same time, to perform the task. Opening a vault with two keys held by different staff, or recovering a master encryption key that has been split into parts held by different custodians (split knowledge), are examples. Two-person integrity is the term used in high-assurance environments for rules that no one may be alone with a critical asset.

Separation of duties is only effective if it is designed into systems and checked. A conflict matrix lists combinations of roles that should never be held by the same person, and operations teams test actual role assignments against it. Small organizations that cannot separate every duty use compensating controls, such as detailed logging reviewed by an independent manager.

# Check role assignments against a separation-of-duties conflict matrix
conflicts = {
    ('change_requester', 'change_approver'),
    ('log_admin', 'domain_admin'),
    ('vendor_create', 'payment_approve'),
    ('backup_operator', 'backup_auditor'),
}
assignments = {
    'akhan':   {'change_requester', 'log_admin'},
    'bmorin':  {'change_approver'},
    'clee':    {'log_admin', 'domain_admin'},
    'dsingh':  {'vendor_create'},
    'eortiz':  {'vendor_create', 'payment_approve'},
    'fnguyen': {'backup_operator'},
}
for user, roles in sorted(assignments.items()):
    found = [f'{a} + {b}' for a, b in sorted(conflicts) if a in roles and b in roles]
    status = 'CONFLICT: ' + '; '.join(found) if found else 'ok'
    print(f'{user:8s} {status}')

akhan    ok
bmorin   ok
clee     CONFLICT: log_admin + domain_admin
dsingh   ok
eortiz   CONFLICT: vendor_create + payment_approve
fnguyen  ok

The check finds two conflicts. In practice the result goes to the access owners, who either remove one role or document a compensating control approved by risk management. Running this kind of test automatically after every access change, rather than once a year, is part of the shift to continuous control monitoring discussed in CISSP-115.

Job rotation and mandatory vacations

Job rotation moves people through different roles over time. It spreads knowledge so that the organization is not dependent on one person, and it acts as a detective control: the person who takes over a role may notice irregularities that the previous holder concealed or never saw. Mandatory vacations serve the same detective purpose. Many banks and regulated firms require staff in sensitive roles to take a block of consecutive days off, during which someone else performs their duties and their access is often suspended. Frauds that depend on continuous concealment, such as lapping receivables or hiding a rogue account, tend to surface when the concealer is away.

Both practices have costs, including training time and temporary loss of expertise, so organizations apply them to roles where the risk justifies them: system administrators with broad privileges, treasury staff, security analysts with access to monitoring tools, and anyone who can approve their own work.

Privileged account management

Privileged accounts, such as domain administrators, root accounts, database administrators, cloud tenant owners and service accounts with broad rights, are the most valuable targets in any environment and the most damaging when misused. Privileged account management (often called privileged access management, PAM) is the operational discipline of controlling them. Its core elements are: an inventory of every privileged account including service and machine identities; separate administrative accounts so that people do not browse the web or read email with administrator rights; credential vaulting, in which the PAM system stores and rotates passwords and keys and releases them only through an approved session; session recording or logging for privileged activity; just-in-time elevation; and regular review of who holds what.

Service level thinking

Operations teams work to commitments. A service level agreement (SLA) is a formal commitment, often contractual, between a provider and a customer: for example, that the managed security service will notify the customer of a critical alert within 15 minutes. An operational level agreement (OLA) is an internal commitment between teams that support an SLA: the network team agrees to apply an emergency firewall block within 30 minutes of a request from the security operations centre. Metrics then show whether the commitments are met. Security managers should insist that security commitments are written into outsourcing contracts and that the provider reports against them, because an unmeasured service level is only a hope.

The security operations centre

A security operations centre (SOC) is the team, processes and technology that continuously monitor an organization's environment, detect and analyse potential security events, and coordinate the response. The word centre suggests a room with screens, and some SOCs are exactly that, but many are now distributed teams working from several locations or entirely remotely, connected by shared tools and runbooks.

A typical SOC has tiers. Tier 1 analysts triage incoming alerts, close obvious false positives and escalate anything suspicious. Tier 2 analysts investigate escalated alerts in depth and lead the response to confirmed incidents of moderate severity. Tier 3 staff, sometimes called threat hunters or senior responders, handle major incidents, look proactively for signs of compromise that alerts missed and improve detection content. Around them sit a SOC manager, detection engineers who write and tune rules, and liaisons to IT operations, legal, privacy and communications.

SOC sourcing models vary. An in-house SOC gives the organization full control and deep knowledge of its environment but is expensive to staff around the clock. A managed security service provider (MSSP) or managed detection and response (MDR) provider supplies monitoring and often initial response as a service, which can give smaller organizations 24-hour coverage they could not otherwise afford. A hybrid model keeps senior analysis and decision-making in house while outsourcing after-hours monitoring or tier 1 triage. Whatever the model, accountability for security stays with the organization: a provider can be contracted to watch, but the organization's own managers still decide on containment that affects the business and still own regulatory obligations.

import math
# How many analysts does one 24x7 seat need?
hours_per_year_seat = 24 * 365
productive_hours_per_analyst = 52 * 40 - (20 + 10 + 5) * 8   # minus vacation, holidays, training days
seats = 2
analysts = seats * hours_per_year_seat / productive_hours_per_analyst
print(f'Seat hours per year: {hours_per_year_seat}')
print(f'Productive hours per analyst: {productive_hours_per_analyst}')
print(f'Analysts for {seats} seats around the clock: {analysts:.1f} -> hire {math.ceil(analysts)}')

Seat hours per year: 8760
Productive hours per analyst: 1800
Analysts for 2 seats around the clock: 9.7 -> hire 10

The arithmetic explains why around-the-clock coverage is so expensive: two seats staffed every hour of the year need about ten analysts before allowing for turnover, sick leave or supervision. This is often the decisive factor in choosing a managed or hybrid model.

Governing security operations

Security operations needs governance like any other function. Responsibilities should be documented in a RACI chart or similar, runbooks and playbooks should exist for routine and emergency tasks, and metrics should be reported to management. The operations team itself must be subject to controls: monitoring tools are powerful, so access to them is restricted, their configuration is change-controlled, and analysts' own activity is logged and reviewed. Staff wellbeing is also a governance concern. Alert fatigue and night shifts contribute to burnout and turnover, which in turn erode the institutional knowledge a SOC depends on. Rotations, realistic staffing and investment in reducing false positives are not luxuries.