On this page
Module 11: Security and Privacy Protocols
Learning Objectives
By the end of this module, you will be able to:
- Verify requester identity and authorization before acting on any account, tenant, or message-level request.
- Apply least-privilege and role-based access principles to every action taken, using only the access level required for the task at hand.
- Correctly handle PII, sensitive email content, and credentials/tokens/secrets encountered during investigation.
- Follow safe, approved procedures for collecting, storing, and transmitting logs, message samples, and evidence.
- Recognize a security or privacy incident and follow the correct evidence-preservation and escalation path.
- Identify, without hesitation, the specific actions a Support Engineer must never perform.
Key Terminology
- Least privilege
- Using only the minimum level of access necessary to complete a specific task, for the shortest necessary time.
- Role-based access control (RBAC)
- Access granted according to a defined role (e.g., L1, L2) rather than broad, undifferentiated access.
- Chain of custody
- A documented, unbroken record of who handled a piece of evidence, when, and what was done to it — necessary if evidence may later support a formal investigation.
- PII (Personally Identifiable Information)
- Data that can identify a specific individual (name, email address, financial/government ID data, etc.) — handling of PII is typically subject to legal/regulatory obligation.
- Tenant separation
- The guarantee that one customer's (tenant's) data is never exposed to, or actioned by, a different customer's context.
- Sanitization
- Removing or masking sensitive content from a log/sample/header before it is shared, stored, or used in training material.
Lesson
Read this module more carefully than most others in this program. It is short compared to the technical modules that surround it, but it carries certification weight that is disproportionate to its length: several of this program's automatic-failure conditions live entirely inside this one module. That is not a scare tactic — it is a statement of fact about how this program is graded, and it should change how you read what follows. This isn't a routine compliance pass-through you can skim once and file away. Everything else in this training teaches you how to investigate and fix things skillfully. This module teaches you the boundaries within which that skill is allowed to operate — and, unlike most technical judgment calls, a handful of these boundaries have no gray area at all.
11.1 Verifying Requester Identity and Authorization
Before you act on any request that touches a customer's mail flow, account, or data, you need to confirm two separate things: who is asking, and whether they are authorized to ask for this specific action. Treat these as two distinct checks performed in sequence, not one combined impression. It is entirely possible for a requester to be exactly who they claim to be — a real, verified employee of the customer organization — while still not holding the authorization needed for the specific thing they're asking you to do. A verified end user, for example, is not automatically authorized to request a tenant-wide policy change just because you've confirmed they work there.
Identity verification itself follows your organization's approved method — a verified admin portal session, a pre-registered list of authorized contacts, a callback to a known number, or something else your organization specifies.
Once identity is confirmed, authorization confirms that this specific, verified person actually holds the role or permission needed for the specific action they're requesting — not just that they're a real, legitimate contact at the customer. Never treat a request as authorized solely because it arrived through an expected channel, such as email or phone, without applying your organization's actual verification method. Channel alone is not proof of identity, and this gap is itself a common social-engineering vector: an attacker impersonating an authorized admin, over a channel that looks routine, to request an action they have no right to request.
11.2 Least Privilege in Practice
Use the lowest level of product or system access that accomplishes the task in front of you. A read-only lookup should never be performed with an account holding write or administrative access if a lesser-privileged option exists and is sufficient — the fact that you could use a more powerful credential is not a reason to. When an investigation genuinely requires temporarily elevated access, scope that elevation specifically to the task at hand and time-box it; elevated access left standing after the task is done is exactly the kind of loose end that turns a routine investigation into an audit finding later.
11.3 Role-Based Access Control — Alignment to the Competency Matrix
The access granted to you at each Support level should track this program's competency matrix. As a general pattern: L1 access is read-mostly and scoped to routine investigation; L2 gains broader diagnostic access and limited change authority; L3 gains the deepest diagnostic access appropriate to escalation work. The point of tying access to level isn't bureaucracy for its own sake — it's that the authorization boundaries in this module (11.4 onward) only work if the access underneath them is actually structured to match. If your day-to-day access doesn't seem to reflect your role, that's worth raising, not working around.
11.4 Customer Consent Requirements
Passive, read-only investigation of a reported issue doesn't require anything beyond normal ticket assignment. Anything beyond that — a policy change, a message release, an allow-list addition — requires the customer's actual authorization for that specific action. A standing, generic consent to "provide support" is not the same thing and does not cover it. Before you perform the action, document consent in the ticket record: who authorized it, when, and for exactly what action. If you can't point to that record afterward, from the organization's perspective the authorization effectively didn't happen.
11.5 Handling Personally Identifiable Information
You will encounter PII constantly in this work — in headers, in message content, in logs. View it only to the extent necessary for the specific diagnostic task in front of you. Never copy or export it beyond the approved case-management system, and never include it in training materials, internal chat, or documentation without sanitizing it first (see 11.10). If a ticket appears to genuinely require handling PII beyond routine header or log review — for example, reviewing message body content that contains personal data as part of a DLP or data-loss investigation — apply the minimum-necessary-exposure principle explicitly, and note in the ticket exactly why body-content review was necessary. That note is what lets someone reviewing the ticket later confirm the exposure was justified rather than incidental.
11.6 Handling Potentially Sensitive Email Content
Message bodies can contain confidential business information, personal data, or content that's sensitive for reasons that have nothing to do with the security question you're actually investigating. Default to header- and metadata-level investigation wherever that's sufficient to answer the diagnostic question — most of the time, it is. Only review body content when the specific investigation actually requires it: confirming what a phishing lure says, or understanding the context around a DLP match, for instance. And even then, view only what's necessary to answer the question — not the entire message end to end out of general curiosity about what else is in there.
11.7 Handling Credentials, Tokens, Secrets, and API Keys
Sometimes a customer's ticket, a log excerpt, or an attachment will contain a credential, token, secret, or API key — often accidentally, pasted into a ticket description without the customer realizing what they've exposed. When that happens: do not use it, do not store it beyond what's operationally necessary to handle the ticket, flag to the customer that it was exposed and should be rotated, and follow your organization's process for securely handling or redacting the exposed material in the ticket record itself. The fact that a secret landed in front of you by accident doesn't make it yours to use — treat an accidentally-exposed credential with the same restraint you'd apply to one you were never supposed to see at all.
11.8 Prohibiting Password Requests
Support Engineers must never ask a customer or end user for their password, under any circumstance, for any purpose — including "just to verify" and "just to test." Read that again: there is no legitimate diagnostic reason that requires a password, full stop. This isn't a matter of degree, and it isn't a rule with situational exceptions that feel reasonable in the moment. If a customer offers a password unprompted — genuinely trying to be helpful, trying to speed things along — decline it, explain briefly why Support never needs or accepts it, and redirect to your organization's approved authentication or verification method instead.
Worked Example: Handling Password Pressure on a Live Call
Picture the call. A customer admin is on the phone, frustrated, trying to get a mail-flow issue resolved quickly. They say: "Look, just use my login, I'll give you the password, it'll save us both twenty minutes of back and forth." Here is what the correct response actually sounds like, said out loud, calmly, without making it a bigger confrontation than it needs to be:
"I appreciate you trying to speed this up, but I'm not able to accept or use your password — that's a hard rule on our side, not a judgment call I can make case by case, and it's actually there to protect your account as much as anything else. What I can do instead is [verify you through our standard method / walk through this with read access I already have / have you perform the one step I'd otherwise need your login for]. Let's do that instead — it won't take much longer."
Notice what that response does: it declines clearly and without hedging, it briefly explains that the rule isn't a personal preference, and it immediately offers a real alternative path forward instead of just leaving the customer stuck. That combination — firm, brief, and constructive — is what keeps a hard "no" from souring the interaction. What it never does, under any version of this conversation, is soften into "well, just this once."
11.9 Safe Collection and Storage of Logs and Message Samples
Collect only what the specific investigation actually needs. Store it only in approved case-management or evidence systems — never on a personal device, in personal cloud storage, or as an unapproved local copy sitting in a downloads folder "for reference." Apply your organization's retention schedule to what you collect, rather than keeping copies indefinitely just in case they turn out to be useful someday.
11.10 Sanitizing Headers and Attachments
Before you use any real customer header, message, or attachment sample in training material, a KB article, or any content that lives outside that specific customer's own ticket, sanitize the identifying details out of it — real names, real domains, real addresses, real financial or personal data, all of it. This program's own examples in Modules 5 and 9 model the standard you're expected to meet: everything used there is constructed or fully sanitized, never a live customer sample used as-is. Hold your own work to the same bar.
11.11 Secure File-Transfer Methods
Transmit logs, samples, or evidence only through your organization's approved secure transfer method. Personal email, unencrypted chat attachments, and general-purpose consumer file-sharing services are all off the table, regardless of how convenient they are in the moment — convenience is not a factor that outweighs the exposure risk here.
11.12 Retention and Deletion Expectations
Evidence and case data should be retained only as long as your organization's policy specifies, and deleted or purged according to that schedule. Indefinite informal retention — a personal folder of "interesting" past tickets you kept because they made good examples — is itself a privacy and security risk, independent of your intent in keeping them. Good intentions don't change what happens if that folder is ever exposed or subpoenaed.
11.13 Audit Logging
Actions you take within the product — especially anything beyond read-only investigation — should be expected to generate an audit trail. Work under the assumption that your actions are logged and reviewable. Think of this as a safeguard that works in your favor as much as the customer's: it's the record that supports you if a decision you made is ever questioned later, showing exactly what you did, when, and in what context.
11.14 Tenant Separation
Never access, reference, or act on one customer's tenant data while you're working a different customer's ticket — even briefly, even just for comparison ("let me check if another customer had this same issue"). That kind of cross-tenant pattern analysis has a legitimate place, but only through an approved, deliberate process conducted by authorized roles using approved tooling — not ad hoc, by an individual engineer navigating between tenant contexts mid-ticket because it seemed convenient.
11.15 Avoiding Unauthorized Configuration Changes
Any configuration change beyond what a specific, authorized ticket calls for is out of scope — even if you're confident it would genuinely improve the customer's security posture. Propose it to the customer as a recommendation instead, and let them authorize it through the normal consent process described in 11.4. A unilateral "helpful" change is still unauthorized, regardless of how good the outcome would have been; the customer's ability to decide what happens in their own environment doesn't get waived just because you thought you knew better.
11.16 Change Approval and Rollback Requirements
Any change with production impact should have a defined rollback plan identified before the change is made — not improvised after something has already gone wrong. It should also follow your organization's change-approval process appropriate to its risk level; Module 17's escalation matrix defines which changes require what level of sign-off. If you can't articulate the rollback plan before you act, that's a sign you're not ready to act yet.
11.17 Message Release Authorization
Releasing a quarantined message that was flagged as an actual security threat — as opposed to a routine policy match — requires explicit authorization through your organization's process. This is one of the highest-risk individual actions a Support Engineer can take, because releasing a message that turns out to actually be malicious directly delivers that threat to the recipient. There's no undo once it's in the inbox.
Worked Example: Two Release Requests, Side by Side
Compare two release requests that arrive looking superficially similar, to see why they take genuinely different paths.
Request A — routine false positive. A customer's newsletter from a known, established sender got caught by a policy rule — say, a bulk-mail threshold — and quarantined. The customer opens a ticket asking for it to be released, and provides enough context to support that this is a routine policy match, not a threat. Here, the approved procedure is to follow the product's defined release workflow with documented customer request and role-appropriate authorization: you note in the ticket who requested it, why, and what evidence supports the false-positive determination, and you proceed at the authorization level appropriate to your role. If anything about the false-positive determination feels ambiguous, that's the signal to loop in L2 before releasing rather than after.
Request B — flagged as malicious. A message was quarantined specifically because it was flagged as a likely threat — credential phishing, malware, or similar — not a routine policy rule. Even if the customer is completely certain it's actually legitimate, this request follows a categorically different path: explicit sign-off per your organization's policy, never a unilateral release, with a full findings write-up and the approver's identity and timestamp documented before the message ever leaves quarantine.
The releases look alike from the outside — both are "just release this one message" — but the risk profile underneath them is not remotely the same, and that's exactly why the authorization requirement scales the way it does.
11.18 Allow-List and Bypass Approval
As established in Module 10 (sections 10.17 and 10.20), allow-list and bypass changes carry a real security trade-off, and they should go through the approval process appropriate to their scope. A narrow, single-sender exception typically carries lower risk and a correspondingly lighter approval burden than a domain-wide or category-wide bypass — and the approval requirement should scale accordingly. The wider the exception, the more it's worth pausing on, because a domain-wide allow-list doesn't just cover the sender you're thinking of right now — it covers every sender at that domain, indefinitely, including ones that don't exist yet.
11.19 Security Incident Recognition
Learn to recognize the Module 9 threat categories and the Module 17 incident-classification criteria that indicate you're looking at a security incident — confirmed account compromise, confirmed malware execution, confirmed BEC payment activity, confirmed data exfiltration — as distinct from a routine support ticket. The moment you recognize one of these, initiate the Module 17 incident escalation path immediately, rather than continuing to work it as a standard ticket a little longer to see how far you can get on your own. Recognition is the trigger; escalation is the immediate next step, not a fallback for when you've exhausted normal troubleshooting.
11.20 Evidence Preservation and Chain of Custody
Once an issue is recognized as a potential security incident, preserve evidence in its original, unmodified form — the original message source, not a paraphrase of what it said; original logs, not a filtered excerpt of the parts that seemed relevant. Then document every subsequent handling step: who accessed the evidence, when, and what was done to it. This documentation may be required to support a later formal investigation, and evidence without a demonstrably intact chain of custody can end up less useful — or entirely unusable — for that purpose, regardless of how sound the underlying finding actually was.
11.21 Legal, Compliance, and Privacy Escalation
Certain findings — confirmed data exposure involving regulated data categories, or a suspected legal or regulatory notification obligation — should be escalated to Legal, Privacy, or Compliance per Module 17's escalation matrix. You are not expected to make legal determinations yourself, such as deciding whether a notification obligation actually exists in a given case. That determination belongs to people with the training and authority to make it. Your job is to recognize the pattern and escalate it promptly, not to guess at the answer yourself and hope you guessed correctly.
11.22 Responsible Disclosure
If you discover a genuine product vulnerability or gap during the course of support work, route it through your organization's internal responsible-disclosure or Product-Security process (Module 17), rather than discussing it externally — with the customer, publicly, or even informally with other contacts — before it has been appropriately assessed and addressed. A real vulnerability is valuable information handled the right way, and a liability if it leaks the wrong way before anyone's had a chance to fix it.
11.23 Internal Need-to-Know Communication
Discuss ticket and incident details only with colleagues who have a legitimate need to know for the purpose of resolving or escalating the issue. This includes internal chat channels — a broad internal channel is not an appropriate venue for sharing sensitive customer detail beyond what's operationally necessary for the specific people actually working the issue, even though it feels like an internal, "safe" audience. Need-to-know is a real boundary internally, not just something that applies to the outside world.
11.24 Prohibited Actions During Malware Analysis
Never execute, open, or interact with suspected malware outside an approved, isolated malware-analysis environment (Module 14) — this includes on a personal device, on a general-purpose company workstation, or "just to see what it does" out of curiosity. Never upload a customer's suspected-malicious file, or any sensitive data associated with it, to an unapproved public analysis service; Module 14's public/private/never-upload data classification governs exactly which tools are appropriate for which kind of sample, and that classification is not optional guidance — it's the boundary.
Actions You Must Never Perform
Everything else in this table has an authorization path — some route, however demanding, by which the action becomes permitted. The items below do not. There is no version of "get sign-off first" that makes these acceptable; the correct action is always to decline and, where relevant, escalate the situation itself.
- Request or accept a customer's or end user's password, for any reason.
- Release a message flagged as malicious or ambiguously suspicious without documented, authorized sign-off.
- Upload customer data, files, URLs, or message content to an unapproved public analysis tool or service.
- Make a production configuration change outside an authorized, documented change process.
- Access, reference, or act on one customer's (tenant's) data in the context of a different customer's ticket outside an approved, deliberate cross-tenant process.
- Execute, open, or interact with suspected malware outside an approved, isolated analysis environment.
- Store customer logs, message samples, or evidence on a personal device, personal cloud storage, or any unapproved location.
- Discuss specific customer or incident details in a venue or with colleagues who have no legitimate need to know.
- Make a legal, regulatory, or notification-obligation determination without escalating to Legal/Privacy/Compliance.
- Disclose a discovered product vulnerability externally before it has gone through the internal responsible-disclosure process.
Hands-On Lab
Lab 11.1 — Action/Risk/Authorization Practicum
You will be given twelve realistic request scenarios, a mix of routine and high-risk, including at least two that are deliberately designed to tempt you toward an automatic-failure action. For each scenario:
- Identify the correct risk tier (low, medium, high, or critical).
- State the required authorization before any action can be taken.
- State the correct next step — including explicitly declining and escalating, where that is the correct answer rather than finding a way to proceed.
Deliverable: a completed worksheet for all twelve scenarios, reviewed against the answer key by a trainer or peer.
Scenario-Based Exercise
Scenario: A frustrated customer admin insists a specific message be released immediately. It was flagged as a likely credential-phishing attempt, and the admin is confident it's actually a legitimate password-reset email their own IT team sent — but the authorized-approver process would take another hour to complete, and the admin says they "don't have time for that."
Task: Draft the exact response you would give: what, if anything, can be done immediately versus what must wait for authorization, and the customer-facing explanation for why the wait exists even though it's genuinely inconvenient for them. Ground your explanation in 11.17 and the authorization table above.
Knowledge Check
Answer each question yourself before expanding it.
1. Why are identity verification and authorization two separate checks, not one?
2. Why is releasing a message flagged as malicious treated as a higher-risk action than releasing a routine false-positive policy match?
3. What should an engineer do if a customer pastes an API key into a ticket description?
4. Why is a domain-wide allow-list request held to a higher authorization bar than a single-sender request?
5. What is the correct response if a customer offers their password unprompted, "to make things faster"?
6. Why does evidence for a suspected security incident need to be preserved in its original, unmodified form?
Common Misconceptions
Key Takeaways
- Treat the automatic-failure-adjacent items in this module — password requests, unauthorized message release, cross-tenant access, unapproved external tool uploads — as zero-tolerance for yourself, not just zero-tolerance on paper. A single real instance of any of these is a serious event, not a note that gets folded into a routine ticket-quality review.
- Never ask for a password. Not "just to verify," not under time pressure, not because the customer offers it first. There is no version of this rule with an exception built in — decide now what you'll say when it comes up, so you're not improvising it live.
- Never release a message flagged as malicious without explicit, documented sign-off — regardless of how confident the customer is that it's actually fine, and regardless of how long the approval process takes. The cost of being wrong here is a threat landing in someone's inbox; there is no version of "expedited" that's worth that risk.
- Never act on another customer's tenant data while working a different customer's ticket — even to glance at it for comparison. Looking is the exposure. If cross-tenant analysis is genuinely needed, that goes through an approved process, not through you personally switching contexts.
- For everything short of these hard boundaries — under-documented authorization, an allow-list scope that's broader than it should be without escalation — use the gap as a concrete teaching moment tied back to the specific row of the Action/Risk/Authorization table it should have followed. Most of this module is about calibrating judgment correctly, not memorizing an absolute rule; know which few items are the exception to that.
- When you're not sure whether something requires authorization, treat that uncertainty itself as the answer: ask before you act. Every row in the authorization table has an escalation point for exactly this reason.