What is Organizational Context?

Organizational context is a feature that allows your organization to share knowledge with Qevlar AI. Instead of relying only on external threat intelligence, you can provide organization-specific information that Qevlar considers when investigating alerts.

For example:

• "The domain cdn.internal-tools.company.com is our internal CDN server hosted on AWS"
• "User svc-monitoring@company.com runs automated health checks every 5 minutes"
• "Connections from IPs in range 10.53.0.0/24 come from our internal Zscaler proxy"

This captures tribal knowledge that usually only lives in analysts' heads or fragmented documentation, and makes it available to every investigation.

What it solves

Without context, even the best SOC tools can waste time or create noise:

• False positives: Investigations flag activity that is normal in your organization (e.g., sanctioned TOR communication, internal scanning tools).
• False negatives: Legitimate threats may be overlooked because the investigation didn't consider business rules (e.g., a finance user receiving unexpected encrypted attachments).
• Lost knowledge: Analyst expertise is often undocumented or siloed, leading to repeated work when new team members investigate similar alerts.

Context reduces these issues by embedding organizational knowledge into every investigation.

How it works

1. You create a context item : Select the observable(s), specify when it applies, and explain why it's allowed or not.
2. Qevlar investigates : When an alert comes in, Qevlar analyzes it and reaches an initial conclusion.
3. Qevlar checks context : Qevlar reviews your context items to see if any match observables in the investigation.
4. Qevlar adjusts if needed : If a context item applies and provides relevant information, Qevlar factors it into its reasoning and may revise its conclusion.

Important: Context influences Qevlar's reasoning but does not override it. Qevlar still checks all evidence and completes the full investigation before making a decision. A context item is one signal among many, if other evidence strongly suggests a threat, Qevlar will factor that in.

When context is used, it appears in the investigation report with the tag "Context Used." You can view which context items were applied and how they influenced the conclusion.

Adding Context

You can add context in two ways:

• From the Context page

1. Click "Context" in the navigation menu
2. Click "+ Add Context"

3. Fill in the form and save

   

• From an investigation

1. Open an investigation
2. Click "Add to Context" in the top right
3. The form opens as a side drawer

4. The context item is automatically linked to the investigation

   

All context items require admin approval before becoming active.

The Context Form

The form captures structured information so Qevlar can reliably interpret and apply your knowledge.

When you see (required)

Select the observable(s) this context applies to. An observable is any entity that appears in an alert and can be analyzed, for example, a file name, IP address, domain, file hash, user account, host, or process.

When you open the form from an investigation, the dropdown lists all observables found in that investigation. Select one or more that your context applies to.

Limit to specific scope (optional)

Narrow the context to specific conditions : a user, host, a path, an alert type etc. Click "+ Limit to specific scope" to expand this section. Leave empty if the context should apply globally.

Example: "file.exe" is the observable, "alice@company.com" is the scope. This means the context only applies when alice runs file.exe, not when other users run it.

Explanation (required)

Describe three things:

1. What the observable is (e.g., "This is our CI/CD build server")
2. What action or behavior you are marking as allowed or not allowed (e.g., "It regularly executes scripts as part of automated deployments")
3. Why this is expected or suspicious : provide business context, references, or justification (e.g., "Approved by IT security team, ticket #12345")

Mark it as (required)

• Allowed: This activity is expected and legitimate
• Not allowed: This activity is suspicious and should be flagged

Expiry date (optional)

Set an expiry date if this context is temporary (e.g., a penetration test window). If not set, the context remains active indefinitely. Only future dates can be selected.

Best Practices

1. Be specific and factual

Your context should contain verifiable facts, not opinions.

❌ "This domain is safe" ✅ "The domain notifications.company.com is our internal infrastructure used for automated employee notifications"

❌ "These alerts are false positives" ✅ "Connections from IPs in range 10.50.0.0/24 come from our internal Zscaler proxy"

2. Describe the action, not just the observable

Don't just identify what something is, explain what behavior you're allowing or flagging.

❌ "svc_backup.exe is a legitimate process" ✅ "The process svc_backup.exe running from C:\Services\ performs nightly backups to our NAS. This scheduled activity between 2-4 AM is expected."

❌ "User admin-it@company.com is trusted" ✅ "User admin-it@company.com runs base64-encoded PowerShell scripts for Intune deployments. This activity is approved by IT security."

3. Explain why

Back up your context with business justification. This helps admins approve it and helps future analysts understand the reasoning.

✅ "The domain updates.vendor-software.com belongs to VendorSoft Inc, our accounting software provider. Downloads from this domain to Finance department workstations are expected for automatic software updates. Contract reference: FIN-2023-089."

❌ "updates.vendor-software.com is safe."

4. Use scope to be precise

Scope controls how broadly your context applies. Finding the right scope is a balance:

• Too broad → risk of missing real threats
• Too narrow → won't catch all legitimate activity

Start narrow and expand only if needed:

• Specific users or hosts
• Time windows (e.g., backup window 2-4 AM)
• Specific file paths or extensions
• Network segments or AD groups

❌ "All connections to Microsoft domains are safe" ✅ "Connections to login.microsoftonline.com for Azure AD authentication are expected"

❌ "PowerShell scripts are approved" ✅ "PowerShell scripts run from C:\Scripts\Approved\ by the IT service account are approved"

5. Set expiry for temporary exceptions

For time-bound activities like penetration tests or vendor access windows, set an active period so the context doesn't persist indefinitely.

❌ "IP 1.2.3.4 is our penetration testing server" ✅ "IP 1.2.3.4 is our penetration testing server" with active period set to the test window

6. Review and maintain

• Delete context items for decommissioned services
• Update context when infrastructure changes
• Review context that hasn't been used in 90+ days

Context by Alert Category

Different alert types benefit from different context:

FAQ

• Does context override Qevlar's verdict? No. Context influences Qevlar's reasoning but doesn't force a specific outcome. Qevlar weighs your context alongside all other evidence. If other signals strongly suggest a threat, Qevlar will factor that into its conclusion.
• Can I see when context was used? Yes. When context influences an investigation, it appears in the report with the tag "Context Used." You can click to see which items were applied.
• Who can create context? Any user can create context items, but all items require admin approval before becoming active.
• Is context shared across profiles? No. Context items are unique to a profile. A context item created for Profile A will not be accessible or referenced by Profile B.