AppSec Process & Architecture
Secure SDLC, secure code review, threat modeling, segregation of duties, vulnerability triage and secure architecture design.
24 questions
JuniorTheoryVery commonWhat does defense in depth mean, and why is a single perimeter control a bad bet?
What does defense in depth mean, and why is a single perimeter control a bad bet?
Controls are layered so no single failure is fatal — an attacker has to defeat several independent ones, and each layer buys detection time. A lone perimeter control is a single point of failure: bypass it once, or start from inside, and nothing else contests the path to the data.
Common mistakes
- ✗Equating layering with duplicating one vendor mechanism twice
- ✗Assuming an internal system may trust the perimeter decision blindly
- ✗Ignoring that many attacks start from inside the perimeter
Follow-up questions
- →How does an extra layer help even when it does not stop the attack?
- →Why do two layers with a shared dependency count as one?
JuniorTheoryVery commonWhy is allowlist input validation not the same defense as contextual output encoding?
Why is allowlist input validation not the same defense as contextual output encoding?
Validation decides at the boundary whether data is acceptable, and an allowlist of what is permitted beats a denylist of known-bad input. Encoding happens later, when data is written into HTML, SQL or a shell, and makes it inert for that interpreter. Neither replaces the other.
Common mistakes
- ✗Believing strict validation removes the need to encode on output
- ✗Encoding once on input instead of per destination context
- ✗Trusting client-side validation as a security control
Follow-up questions
- →Why does the same value need different encoding for HTML and for a shell?
- →When is a denylist the only option, and what do you add to compensate?
MiddleDesignVery commonThe avatar-upload flow: user → upload API → filename in the DB → image into file storage → serving to the browser. Describe the attack vectors, sort them by criticality and pick a defense for each. Account for a malicious file, SQLi via the filename, an oversized file, unauthorized upload and read, and disclosure of internal information through errors.
The avatar-upload flow: user → upload API → filename in the DB → image into file storage → serving to the browser. Describe the attack vectors, sort them by criticality and pick a defense for each. Account for a malicious file, SQLi via the filename, an oversized file, unauthorized upload and read, and disclosure of internal information through errors.
High: malicious upload — antivirus, validate real type, store outside web root; SQLi via filename — parameterized queries; unauthorized read — authorize every fetch. Medium: oversized-file DoS — cap POST body; unauthorized-upload DoS — authorize the endpoint. Low: interception — TLS. Rank by impact, not ease of attempt.
Common mistakes
- ✗Determining the file type by extension rather than by its real content
- ✗Storing uploaded files inside the web root where they can be executed
- ✗Ranking vectors by ease of attempt instead of by impact
Follow-up questions
- →Why is storing uploaded files outside the web root more important than checking the extension?
- →How can a filename from the request lead to SQL injection?
MiddleDesignVery commonYou have two transfer forms: between your own accounts (including currency accounts) and to third-party cards by number. Perform threat modeling: list the attack vectors and a control for each. Account for source-account tampering, transferring a negative amount, viewing other users' balances, enumerating card numbers, tampering with the conversion parameter, rounding errors, a race condition, SQLi, CSRF, XSS and DoS via numbers in exponential notation.
You have two transfer forms: between your own accounts (including currency accounts) and to third-party cards by number. Perform threat modeling: list the attack vectors and a control for each. Account for source-account tampering, transferring a negative amount, viewing other users' balances, enumerating card numbers, tampering with the conversion parameter, rounding errors, a race condition, SQLi, CSRF, XSS and DoS via numbers in exponential notation.
Map each vector to a control: object-level authorization on the source account; reject non-positive amounts; authorize balance reads; rate-limit card lookups (enumeration); pin the rate server-side; exact decimal money types; a transaction with locking (race); parameterized queries; anti-CSRF tokens; output-encoding; validate numeric ranges (DoS).
Common mistakes
- ✗Relying on client-side validation instead of server-side checks
- ✗Treating the fact of login as sufficient authorization to access a specific account
- ✗Storing money in float and forgetting about rounding errors
Follow-up questions
- →Why do client-side checks not count as a security control here?
- →How does transferring a negative amount differ from source-account tampering in the type of control?
MiddleTheoryVery commonWhere are the trust boundaries in a three-tier web application, and what must sit on the trusted side?
Where are the trust boundaries in a three-tier web application, and what must sit on the trusted side?
A boundary is any hop where data changes owner — browser to server, server to database, server to a third party. Everything that must not be bypassed lives on the far side of it, so authorization, validation and business rules are re-decided server-side; the client is convenience only.
Common mistakes
- ✗Treating the network perimeter as the only boundary in the system
- ✗Counting client-side checks as server-side enforcement
- ✗Trusting an internal service call because it never leaves the datacenter
Follow-up questions
- →Why is the call from your server to a third-party API also a boundary?
- →Which checks may stay on the client, and purely for what reason?
JuniorTheoryCommonWhy do fail-secure defaults beat opt-in hardening when a check or dependency fails?
Why do fail-secure defaults beat opt-in hardening when a check or dependency fails?
The default answer is deny — access exists only where an explicit rule grants it, and when a check throws or an authorization service times out the request is refused rather than let through. Opt-in hardening leaves every forgotten switch insecure, and forgetting is the normal case.
Common mistakes
- ✗Letting a request through when the authorization service is unavailable
- ✗Believing a hardening checklist replaces a safe out-of-the-box default
- ✗Treating deny-by-default as merely an inconvenience for support
Follow-up questions
- →When is failing open a deliberate and defensible choice?
- →Why is a default deny easier to audit than an opt-in list?
JuniorTheoryCommonWhy does least privilege limit blast radius, and how does it decay as roles accrete?
Why does least privilege limit blast radius, and how does it decay as roles accrete?
Each identity gets only the rights its task needs, so a compromised account or a bug reaches a slice of the data instead of the whole system. It decays because rights are added on request and never revoked, so accounts accrete permissions until recertification removes them.
Common mistakes
- ✗Assuming a grant is safe forever because it was justified once
- ✗Confusing least privilege with a perimeter control that stops entry
- ✗Never recertifying access, so leavers and movers keep old rights
Follow-up questions
- →How does an access recertification review actually find accreted rights?
- →Why is a temporary elevation safer than a permanent role grant?
JuniorTheoryCommonHow does the threat-classification mnemonic STRIDE turn a data-flow diagram into concrete threats?
How does the threat-classification mnemonic STRIDE turn a data-flow diagram into concrete threats?
The diagram names processes, stores, flows and trust boundaries, so every threat attaches to a concrete element. STRIDE then walks each element for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
Common mistakes
- ✗Treating STRIDE as a severity score instead of an enumeration aid
- ✗Drawing the diagram without marking trust boundaries, so threats stay abstract
- ✗Starting threat modelling only after the implementation is finished
Follow-up questions
- →Why does a trust boundary on the diagram change which threats you look for?
- →Which STRIDE category covers a missing audit trail, and why?
JuniorDesignCommonYou are triaging a bug bounty report. The report: SQL injection in course search (parameter q), PoC ' UNION SELECT 1,1,1 -- returns 1 1 1. What questions do you ask the reporter and the team, and how do you rate criticality if the DB account enforces the principle of least privilege?
You are triaging a bug bounty report. The report: SQL injection in course search (parameter q), PoC ' UNION SELECT 1,1,1 -- returns 1 1 1. What questions do you ask the reporter and the team, and how do you rate criticality if the DB account enforces the principle of least privilege?
Confirm the PoC reproduces, then scope impact: which tables the account reads, whether it can write, whether PII is reachable. If least-privilege holds (read-only public catalog) the injection is real but low criticality. Impact sets severity.
Common mistakes
- ✗Rating criticality by the vulnerability class without assessing real impact
- ✗Rejecting a valid PoC by demanding a full data dump up front
- ✗Ignoring the DB account's privileges and the reachability of PII/secrets
Follow-up questions
- →Why does least privilege on the DB account lower the injection's criticality without removing the bug?
- →What questions would you ask if that same account has write access?
MiddleDesignCommonA pull request changes authentication for your internal admin console. It adds a remember-me cookie that lasts 90 days, moves the session identifier into a URL query parameter so a legacy reporting tool can pass it around, and skips the second factor whenever the request arrives from the office IP range. You have one hour to security-review it and cannot block the release for a full redesign. Describe how you prioritise the review — what you inspect first and why, which of the three changes you refuse outright, which you can accept with conditions, and what evidence you ask the team to produce before the release goes out.
A pull request changes authentication for your internal admin console. It adds a remember-me cookie that lasts 90 days, moves the session identifier into a URL query parameter so a legacy reporting tool can pass it around, and skips the second factor whenever the request arrives from the office IP range. You have one hour to security-review it and cannot block the release for a full redesign. Describe how you prioritise the review — what you inspect first and why, which of the three changes you refuse outright, which you can accept with conditions, and what evidence you ask the team to produce before the release goes out.
Review by blast radius, not diff order. Refuse the session id in the URL — it leaks through logs, referrers and shared links. Refuse the IP-based factor bypass — a network range is not an identity. Accept the long cookie only as a separate low-privilege token with server-side revocation.
Common mistakes
- ✗Treating an internal console as out of scope for authentication review
- ✗Accepting a network range as proof of identity for skipping a factor
- ✗Believing a gateway filter compensates for a broken session design
Follow-up questions
- →Why does a session identifier in a URL leak in ways a cookie does not?
- →What conditions make a long-lived remember-me token acceptable?
MiddleDesignCommonDescribe the SDLC from a security standpoint: which controls to embed at each stage — from business requirements to production support — and why. Where do SAST, fuzzing, SCA (software composition analysis), DAST and pentest apply, and why exactly at those stages?
Describe the SDLC from a security standpoint: which controls to embed at each stage — from business requirements to production support — and why. Where do SAST, fuzzing, SCA (software composition analysis), DAST and pentest apply, and why exactly at those stages?
Shift security left, matching each control to what is inspectable at that stage: requirements → security requirements; design → architecture review; code → SAST; tests → fuzzing; build → SCA; test → DAST; e2e → pentest; prod → smoke tests; support → patching.
Common mistakes
- ✗Reducing security to a single pentest before release
- ✗Confusing the stages where SAST (code) and DAST (running application) apply
- ✗Forgetting the support stage — patching, log analysis and scanning
Follow-up questions
- →How does SAST coverage at the code stage differ from DAST on a running application?
- →Why is SCA (software composition analysis) placed at the artifact build stage?
MiddleDesignCommonYou are designing session handling for a payments web application. Users sign in with a password, can add a payee, can raise their own transfer limit, and an operator may be granted a temporary elevated role during a support call. The frontend is a single-page application, and today the session is one cookie issued at login and kept until the browser closes. Design the session layer so that a stolen or fixated session cannot survive a privilege change — state what happens to the identifier at login, at elevation, at logout, on idle and on absolute timeout, where session state is authoritative, and how the cookie itself is protected.
You are designing session handling for a payments web application. Users sign in with a password, can add a payee, can raise their own transfer limit, and an operator may be granted a temporary elevated role during a support call. The frontend is a single-page application, and today the session is one cookie issued at login and kept until the browser closes. Design the session layer so that a stolen or fixated session cannot survive a privilege change — state what happens to the identifier at login, at elevation, at logout, on idle and on absolute timeout, where session state is authoritative, and how the cookie itself is protected.
Issue a fresh identifier at login and again at every privilege change, invalidating the previous one — that kills fixation and stale elevation. Keep session state server-side so logout and revocation are real, enforce both idle and absolute timeouts, and set the cookie HttpOnly, Secure and SameSite.
Common mistakes
- ✗Keeping the same identifier across a login or a privilege change
- ✗Assuming deleting a cookie client-side revokes a stateless token
- ✗Replacing an absolute timeout with an IP binding as theft detection
Follow-up questions
- →Why does session fixation stop working once the identifier is re-issued?
- →What breaks if the elevated role lives only in a client-held token?
SeniorDesignCommonYour product has strong authentication — a password hashed with the memory-hard function Argon2id plus a mandatory second factor from an authenticator app. Support keeps escalating users who lost their phone, and the proposed fix is a recovery flow in which an agent verifies the caller by date of birth and the last four digits of a payment card, then clears the second factor immediately. Design account recovery so it does not become the weakest path into the account — what evidence you accept, what an agent may and may not do alone, which recovery options you offer instead, and what the user sees after a recovery attempt.
Your product has strong authentication — a password hashed with the memory-hard function Argon2id plus a mandatory second factor from an authenticator app. Support keeps escalating users who lost their phone, and the proposed fix is a recovery flow in which an agent verifies the caller by date of birth and the last four digits of a payment card, then clears the second factor immediately. Design account recovery so it does not become the weakest path into the account — what evidence you accept, what an agent may and may not do alone, which recovery options you offer instead, and what the user sees after a recovery attempt.
Recovery must be as strong as the login it bypasses, or attackers use it. Prefer self-service with recovery codes or a second enrolled factor over agent judgement — knowledge answers are public data. No agent clears a factor alone; require a delay, an unsuppressible notification and an audit trail.
Common mistakes
- ✗Accepting knowledge answers that are public or breached data as evidence
- ✗Letting one support agent remove a factor with no delay or second approver
- ✗Suppressing the notification so the real owner never learns of the attempt
Follow-up questions
- →Why does a delay before recovery completes help the legitimate owner?
- →What makes pre-issued recovery codes stronger evidence than an agent call?
SeniorDesignCommonYou are designing the audit-log subsystem for a service that handles payments and personal data. An investigator must be able to reconstruct who did what to which record, developers read the same logs during incidents, and the security team wants events shipped to a SIEM (security information and event management platform) that several teams can query. A developer proposes logging the full request and response body of every API call so that nothing is ever missing. Design the subsystem — what each event must carry, what must never reach the log, who may read and who may delete, and how the record stays trustworthy against an insider.
You are designing the audit-log subsystem for a service that handles payments and personal data. An investigator must be able to reconstruct who did what to which record, developers read the same logs during incidents, and the security team wants events shipped to a SIEM (security information and event management platform) that several teams can query. A developer proposes logging the full request and response body of every API call so that nothing is ever missing. Design the subsystem — what each event must carry, what must never reach the log, who may read and who may delete, and how the record stays trustworthy against an insider.
Log security-relevant events with actor, action, target, source, outcome and time — not raw bodies. Credentials, tokens, keys, full card numbers and excess personal data must never be written. Writers cannot delete — ship append-only to storage the service and its admins cannot rewrite.
Common mistakes
- ✗Logging entire request bodies and thereby writing secrets and personal data
- ✗Giving the writing service delete or update rights on its own audit trail
- ✗Confusing encryption at rest with protection against modification by an insider
Follow-up questions
- →Why is read access to an audit trail itself a privacy decision?
- →What makes an append-only pipeline credible if the same team runs it?
SeniorDebuggingCommonFind the vulnerabilities in a money-transfer service on Spring
Find the vulnerabilities in a money-transfer service on Spring
Race: read-check-write isn't atomic — fix with a transaction and pessimistic lock. Broken validation: a negative amount bypasses the balance check. Broken authorization: no ownership check on fromId, plus exposed Actuator (heapdump) and H2 leak data. DoS: unbounded BigDecimal — cap it. Add @ControllerAdvice against stack-trace leaks.
Common mistakes
- ✗Fixing the race with synchronized instead of a transaction with a DB lock
- ✗Assuming Actuator and the H2 console are safe by default
- ✗Skipping the account-ownership check and the amount-sign check
Follow-up questions
- →Why is a pessimistic lock in a transaction more reliable than synchronized for a transfer?
- →How does a negative amount bypass the balance check in this code?
SeniorDesignCommonYour service integrates with a third-party payment provider. It holds an API credential for that provider, a signing key for outbound webhooks, and a data key that encrypts stored payout details. Today all three live in environment variables baked into the container image, one operations engineer knows their values, and nothing has been rotated in two years. Design the secret and key management architecture — where the material lives, how the application obtains it at run time, how rotation happens without downtime for either the provider credential or the data key, and how you bound the damage if exactly one of the three leaks.
Your service integrates with a third-party payment provider. It holds an API credential for that provider, a signing key for outbound webhooks, and a data key that encrypts stored payout details. Today all three live in environment variables baked into the container image, one operations engineer knows their values, and nothing has been rotated in two years. Design the secret and key management architecture — where the material lives, how the application obtains it at run time, how rotation happens without downtime for either the provider credential or the data key, and how you bound the damage if exactly one of the three leaks.
Keep key material in a managed KMS or HSM and let the service fetch short-lived credentials by workload identity, never from an image. Use envelope encryption so data keys are wrapped by a key that never leaves the KMS. Keep two versions live so rotation overlaps, and scope every key to one purpose.
Common mistakes
- ✗Baking secrets into an image or repository instead of fetching them at run time
- ✗Rotating with a single live version, which forces downtime or a failed verify
- ✗Reusing one secret for several purposes so a single leak affects everything
Follow-up questions
- →Why does envelope encryption make re-keying stored data cheap?
- →What has to be true of the workload identity for this design to hold?
SeniorDesignCommonA multi-tenant SaaS analytics product keeps every customer in one shared PostgreSQL database and one shared object-storage bucket, separated only by a tenant identifier column that the application appends to each query. A new enterprise customer wants proof that no other tenant can read their data even if an application bug ships or a support account is compromised. You cannot move to a database per tenant this quarter. Design the isolation architecture — where the tenant identity comes from, what enforces it below the application, how a cross-tenant read is detected, and what you can honestly promise the customer.
A multi-tenant SaaS analytics product keeps every customer in one shared PostgreSQL database and one shared object-storage bucket, separated only by a tenant identifier column that the application appends to each query. A new enterprise customer wants proof that no other tenant can read their data even if an application bug ships or a support account is compromised. You cannot move to a database per tenant this quarter. Design the isolation architecture — where the tenant identity comes from, what enforces it below the application, how a cross-tenant read is detected, and what you can honestly promise the customer.
Derive the tenant from the authenticated session, never from a request parameter, and enforce it below the application — row-level security or per-tenant credentials — so a forgotten filter returns nothing instead of everything. Alert on cross-tenant access, and test the boundary continuously.
Common mistakes
- ✗Taking the tenant identifier from a client-supplied request field
- ✗Enforcing isolation only in application code that a single bug can bypass
- ✗Promising isolation guarantees that the shared architecture cannot back
Follow-up questions
- →Why does a failure in the application become harmless under row-level security?
- →How do you test the tenant boundary automatically on every deployment?
JuniorDesignOccasionalA customer wants to roll a new system out to production. Prepare a list of questions from information security before launch. What must you find out about the system's purpose, the data it processes, its interaction with critical systems (payment gateway, banking secrecy, PII), the access-control model, logging, external exposure, and the exposure-application-DB architecture?
A customer wants to roll a new system out to production. Prepare a list of questions from information security before launch. What must you find out about the system's purpose, the data it processes, its interaction with critical systems (payment gateway, banking secrecy, PII), the access-control model, logging, external exposure, and the exposure-application-DB architecture?
Ask what the system does and which critical systems it touches (payments, PII), what data it processes, the access-control model (AD/IDM), internet exposure, logging completeness, where sensitive data is stored, and the architecture (who authorizes each hop).
Common mistakes
- ✗Reducing intake to functional QA without establishing the data classification
- ✗Treating HTTPS as sufficient and not asking about the access model and segmentation
- ✗Not clarifying logging completeness, without which an incident investigation is impossible
Follow-up questions
- →Why does the classification of the processed data determine the depth of the other checks?
- →What questions are added if the system interacts with the payment perimeter?
MiddleTheoryOccasionalWhen may you lower a scoring-standard CVSS rating for exploitability or reachability in triage?
When may you lower a scoring-standard CVSS rating for exploitability or reachability in triage?
The base score rates the flaw in the abstract; the environmental and temporal metrics rate your deployment. Lower it when the vulnerable path is unreachable, the preconditions cannot hold, or a compensating control blocks it — never because no public exploit exists yet.
Common mistakes
- ✗Downgrading only because no public exploit has been released
- ✗Refusing to use environmental metrics and shipping the raw base score
- ✗Assuming a dependency is safe because the component is not internet-facing
Follow-up questions
- →How do you evidence that a vulnerable code path is genuinely unreachable?
- →Why must a compensating control be documented with the downgraded score?
MiddleDesignOccasionalThe DB is managed by administrators with super-admin accounts, while the application has owner access to the data. How do you protect sensitive columns from being read and modified by the DB admins themselves (segregation of duties)? When do you choose hashing, when symmetric, when asymmetric encryption, and how do you ensure the integrity of rows and their ordering?
The DB is managed by administrators with super-admin accounts, while the application has owner access to the data. How do you protect sensitive columns from being read and modified by the DB admins themselves (segregation of duties)? When do you choose hashing, when symmetric, when asymmetric encryption, and how do you ensure the integrity of rows and their ordering?
Protect at the application layer, not the DBMS (DB-level encryption only stops backup admins). Prefer hashing where you only verify (passwords); asymmetric crypto when one party writes and another reads; otherwise symmetric. The app holds the keys, so admins see only ciphertext. For integrity add a keyed row hash, chained to the previous row.
Common mistakes
- ✗Relying on DBMS encryption, which only protects against backup admins
- ✗Storing an integrity hash without a secret salt known only to the application
- ✗Not distinguishing the scenarios for hashing, symmetric and asymmetric crypto
Follow-up questions
- →Why does DBMS-level encryption not protect the data from the DB admins themselves?
- →Why is a chain of row hashes needed to protect their ordering?
SeniorDesignOccasionalA bank integrates with an exchange: automated-trading servers reach the exchange over an API, while an operator works through a terminal. Design a secure integration. What questions should you ask, what security controls should you apply, what requirements apply to the operator workstation, the servers and data transfer? When do you choose mTLS and when IPsec with OAuth, and how do you ensure the integrity of trading orders?
A bank integrates with an exchange: automated-trading servers reach the exchange over an API, while an operator works through a terminal. Design a secure integration. What questions should you ask, what security controls should you apply, what requirements apply to the operator workstation, the servers and data transfer? When do you choose mTLS and when IPsec with OAuth, and how do you ensure the integrity of trading orders?
Clarify scope first (exchange requirements, operator functions, data, OS/DB), then apply controls: endpoint protection, DLP, SOC monitoring. Segment the network; isolate the operator workstation (no internet) with 2FA; API behind a WAF with ACL; never publish the DB. Use mTLS for intermittent links or IPsec + OAuth for a persistent channel; sign every order.
Common mistakes
- ✗Exposing the trading API and DB externally instead of segmentation and WAF/ACL
- ✗Choosing a transport without regard for link persistence (mTLS vs IPsec+OAuth)
- ✗Treating channel encryption as sufficient, without signing orders for integrity
Follow-up questions
- →Why is mTLS more appropriate for an intermittent link and IPsec+OAuth for a persistent one?
- →Why sign each order with a certificate on top of channel encryption?
SeniorDesignOccasionalAn internal platform runs forty services on one flat network. Any service can reach any other, calls carry no identity beyond the caller being inside the VPN, and authorization happens only at the public API gateway. After a phishing incident gave an attacker a foothold on one build agent, leadership asks for a zero-trust design. The services must keep running throughout the migration and cannot all be rewritten at once. Design the target state and the first two migration steps — what identity a call carries, where an authorization decision is made, what you stop trusting, and how you avoid an outage when default-deny is switched on.
An internal platform runs forty services on one flat network. Any service can reach any other, calls carry no identity beyond the caller being inside the VPN, and authorization happens only at the public API gateway. After a phishing incident gave an attacker a foothold on one build agent, leadership asks for a zero-trust design. The services must keep running throughout the migration and cannot all be rewritten at once. Design the target state and the first two migration steps — what identity a call carries, where an authorization decision is made, what you stop trusting, and how you avoid an outage when default-deny is switched on.
Stop treating network location as identity. Every call carries a verifiable workload identity — mTLS certificates rotated automatically — and each service authorizes the caller per request, with the end-user context passed along. Roll out identity in observe mode first, then switch service pairs to default-deny.
Common mistakes
- ✗Treating network segmentation alone as a zero-trust architecture
- ✗Sharing one certificate across services, which destroys per-workload identity
- ✗Enabling default-deny without an observation phase and causing an outage
Follow-up questions
- →Why must the end-user context travel with the call and not stop at the gateway?
- →What does the observation phase have to show before default-deny is safe?
SeniorDesignRareYou are the new CISO at a company that has never had information security before. From the domains (Strategy, Architecture, AppSec, Access Management, Asset Inventory, Network/Perimeter/Endpoint/Data Security, Vulnerability Management, Monitoring, Incident Response, Pentest, Forensics, Compliance, Vendor Management, PII Protection, Standards and Policies, BCM, Antifraud) pick three processes each for the first, second and third wave over 6 months, 1 year and 3 years. How do you justify the order?
You are the new CISO at a company that has never had information security before. From the domains (Strategy, Architecture, AppSec, Access Management, Asset Inventory, Network/Perimeter/Endpoint/Data Security, Vulnerability Management, Monitoring, Incident Response, Pentest, Forensics, Compliance, Vendor Management, PII Protection, Standards and Policies, BCM, Antifraud) pick three processes each for the first, second and third wave over 6 months, 1 year and 3 years. How do you justify the order?
Reason the order from context, not from memory. Learn the business and assets, ask IT and stakeholders about real incidents and regulator requirements, and build the strategy from those problems. A defensible first wave is Inventory → Strategy → Architecture (you cannot protect unknown assets); add Compliance if regulation dominates.
Common mistakes
- ✗Starting with monitoring/SOC before asset inventory and strategy
- ✗Copying a fixed list without tying it to the business context and regulators
- ✗Substituting a single pentest report for a strategy
Follow-up questions
- →Why does asset inventory usually precede monitoring and response?
- →How can a regulator's requirements change your first wave of processes?
