Security you
can inspect.
Your systems deserve more than a promise.
Government software needs protection in the application, the infrastructure, and the way it is operated. We build across all three. See our controls, explore the requirements behind them, and compare the results with the software you use today.
Talk through your security requirementsEvidence you
can open now.
Application controls, engineering tests, release checks, and operational support all contribute to protecting your systems. The public scans show one part of that work.
- Application security
- Organization permissions, Microsoft identity, encrypted financial fields, and authenticated IRS integrations in our ByteWish work.Explore the implemented controlsSee the filing workflow
- Engineering and release checks
- Unit, API, and browser tests for this site's authentication, session isolation, delivery retries, streaming, and staff actions. Dependency auditing and an explicit public build allowlist.Inspect the release processSee what we validate
- Public scan results
- Dated security, performance, and accessibility measurements for this website, including OWASP ZAP, HTTP Observatory, Lighthouse, axe, and IBM Equal Access.Read the security resultsQuality summary JSON
- APIs you can inspect
- Source-verified Appointments and Accessibility examples with Scalar references and downloadable OpenAPI contracts.Appointments APIAccessibility API
- Operations and accountability
- Assigned emergency support during nights, weekends and holidays; Azure point-in-time backups; public availability monitoring.Delivery and support coverageService status
Test the protection.
Publish the results.
We use Mozilla HTTP Observatory and ZAP to examine web security. This website is one example of the checks we put our work through.
Website security results
ZAP 2.17.0
0 high · 0 medium · 0 low risk alerts
4 informational findings retained for review.
Scan coverage and report
Pages: Home, Delivery and support, Appointments, Careers, Contact, LRC case study, ByteWish case study, Accessibility case study, Security and trust, Security standards, Procurement information, Writing a software RFP, County government, Capability brief, Privacy policy, Validation example.
ZAP examines responses from the built website using the same security header policy generated for Cloudflare Pages. Observatory examines the named HTTPS deployment.
- Informational: Modern Web Application
- Informational: Information Disclosure - Suspicious Comments
Reviewed scanner findings:
- Absence of Anti-CSRF Tokens (appointments.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (delivery.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (privacy.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (accessibility.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (capabilities.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (lrc.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (counties.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (standards.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (rfp.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (contact.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (bytewish.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (careers.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (procurement.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (index.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (trust.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Absence of Anti-CSRF Tokens (quality.html): false-positive. The chat form submits through a same-origin JSON API requiring X-Website-Chat and explicit Bearer authorization. Cookies do not authenticate chat. CSP blocks native form submission. Cross-origin and missing-header requests are rejected in automated API tests. Defense documentation.
- Private IP Disclosure (assets/api/reference.js): false-positive. The matched address is a single occurrence in the pinned Scalar dependency’s Faker example-address dataset. It is illustrative library data, not an application endpoint or internal network configuration. This review requires the exact asset, known dataset and unique literal; other addresses remain actionable. The original alert is retained. Defense documentation.
Independent grades.
Open reports.
Check the results yourself. Every grade below names the tested host, the date and the report behind it. You can see what passed and where work remains.
These independent checks sit alongside our application tests, access controls, release checks and recovery arrangements.
- Browser and application protections
- Open the dated Observatory result and reviewed ZAP findings. Our browser tests also exercise conversation access, authenticated staff actions and rejection of altered scripts and styles. Open the results and tested host Download the security results (JSON)
- Availability and escalation
- Check current service status and the published availability record. Existing clients can reach their assigned emergency support contact around the clock, including holidays. Check current service status See who to contact after hours
- Cloud provider assurance
- Review Microsoft's and Cloudflare's own compliance materials, then match the services and responsibilities to your deployment. Our standards guide explains the application work around those foundations. Microsoft Service Trust Portal Cloudflare compliance resources See system and framework requirements
- Security reporting
- Our machine-readable security contact is published at the standard security.txt address. Send vulnerability details to our security inbox; use assigned emergency support for an urgent client incident. Open our security.txt Report a security issue
How to read security grades and audit reports
Download the independent assessment summaries (JSON). Each record includes the tested host, report date, category results and remaining findings.
A TLS grade describes the tested host. Company ratings from Black Kite, SecurityScorecard and RiskRecon have their own scope and scoring. Ask for the dated report, the domains it covers and the findings behind the number.
For an audit or certification, check the named service, assessment period, assessor, exceptions and customer responsibilities. A provider's report describes that provider's controls; our application and operating controls need their own evidence.
What is your
vendor checking?
Put your current application through the same public tests. Use its public web address to inspect browser protections, TLS, internet standards, performance and accessibility. Compare the findings as well as the headline grades.
Talk through your results with usCompare your public application
Choose a test for . Each opens the test provider in a new tab. For Internet.nl, enter the website's domain in its website test or your mail domain in its email test.
| Check | Our release target | Evidence to compare |
|---|---|---|
| Lighthouse | 100 in performance, accessibility, best practices, and SEO. | Run the same page on mobile and desktop. Our published report records every page, profile, and run. |
| HTTP Observatory | A+ with every test passed. | Compare the named host’s grade and failed checks with our dated scan. |
| axe and IBM Equal Access | Zero automated violations against WCAG 2.2 AA and applicable AAA checks. | Check representative pages and workflows with both engines. Include the human review items and their disposition. |
| TLS and certificates | Trusted certificates and strong transport encryption. | Check the exact public host in SSL Labs. Review protocol support, certificate expiry and the findings behind its grade. Open our verification links. |
| ZAP and browser checks | Zero high, medium, or low risk alerts after review. Invalid access and altered resources are rejected. | Ask for the scan scope, reviewed findings, fixes, and access-control test results. Download our security summary. |
Download the vendor comparison worksheet (CSV). Record each vendor’s results, dates, scope, and evidence in the same sheet.
Check your application in Observatory or open PageSpeed Insights directly if you prefer to enter its address there.
How to make the comparison useful
Test the same pages and devices. PageSpeed Insights runs Lighthouse on a public page; it does not exercise signed-in workflows. For those, ask for accessibility and security evidence from the actual application, including manual review.
Read the findings, dates, coverage, and fixes alongside the score. Ask your vendor for authorized ZAP or penetration-test results, then check which application controls were tested. Our release tests reject invalid conversation access and altered scripts and styles, as well as checking every public page.
Inspect our full validation report or bring your requirements to a security review.
Requirements belong
in the software.
We turn your requirements into controls, tests, and evidence for the information your system handles and the people using it.
We build on Azure Government for FedRAMP High requirements, enforce application controls, and tie test evidence to releases.
- Government cloud and contracts
- FedRAMP High, GovRAMP, TX-RAMP, CMMC and NIST SP 800-53. See requirements and evidence.
- Application security and secure delivery
- OWASP ASVS, NIST SSDF, CIS Controls and NIST CSF. See requirements and evidence.
- Accessible public services
- WCAG 2.2, Section 508, ADA Title II and EN 301 549. See requirements and evidence.
- Sensitive and regulated government data
- NIST SP 800-171, CJIS and IRS Publication 1075. See requirements and evidence.
Protection built
into the application.
A secure cloud foundation is the starting point. The application has to enforce its own rules. Open a safeguard to see how this website puts it into practice.
Browser and transport
Encrypted connections and strict transport
The site uses HTTPS. HTTP Strict Transport Security tells browsers to keep using HTTPS for this domain and its subdomains. The security tests check that policy on every redesigned page.
Content Security Policy
The page policy starts with default-src 'none' and permits the resources the site needs. Inline metadata scripts use content hashes. Framing, base URL changes, and native form submission are blocked. Browser checks attempt to run an unapproved script and confirm that it is rejected.
Subresource Integrity
Every external page script and stylesheet has a SHA-384 digest generated from its final delivered bytes. Automated browser tests alter JavaScript and CSS and confirm that the browser refuses to load them. An Integrity-Policy header also requires script integrity metadata in supporting browsers.
Cross-origin isolation and browser permissions
Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy isolate the page from other origins. Automated checks verify crossOriginIsolated on every page. Permissions Policy disables camera, microphone, geolocation, payment, and USB access for these pages.
Conversation and integration security
Separate visitor conversations
Each visitor conversation uses an expiring credential. The browser keeps it in tab-scoped session storage and sends it explicitly to the API. The server stores a token hash and checks the conversation on every authenticated request. Chat does not use cookies for authentication.
Request validation and bounded use
Chat writes require a matching website origin and a custom request header. The backend validates message and picture input and limits requests, conversation images, and AI usage. Automated tests exercise invalid credentials, cross-origin requests, and limits.
Protected pictures
Pictures are checked for supported formats and size limits. Website access requires the matching conversation credential; Teams uses a signed, expiring image link. The pictures are delivered inside the message. Browser and API tests verify that an unrelated visitor cannot retrieve them.
Authenticated Teams replies
The backend verifies Microsoft Bot Framework signatures, the intended application, and the trusted Teams service address. It accepts staff messages only from the configured team and channel, then connects replies to an active visitor thread.
Inspect the all-page browser and accessibility results. The controls above describe this website's implementation; client systems are designed around their own users, data, and permissions.
Security where
the work happens.
Payroll, banking details, and tax returns need protection at every step. Our work for ByteWish Foundation shows how identity, permissions, encryption, and authenticated integrations fit together in a financial application.
Identity and permission
Microsoft sign-in and API token checks
The ByteWish application uses Microsoft identity. Its API checks token signatures, audience, and expiry. The application then checks the person and organization for the requested operation.
Organization-specific authority
Form 990-PF transmission requires administrator permission in the selected organization. The return is retrieved using both its identifier and that organization. Signing in and having authority to submit a particular organization's return are separate checks.
Verified employee signatures
Employee self-submission of a federal W-4 requires a verified WebAuthn passkey assertion. Verification checks the credential and its relationship to the person; the stored record retains the form version, signer, time, and credential reference.
Financial data and integrations
Application-level field encryption
Bank account details and taxpayer identifiers are encrypted by the application. Form 990-PF data, attachment metadata, and employee withholding elections use encrypted fields. Protection is applied to those sensitive records within the application, alongside its access checks.
Managed identity between services
The deployed application uses Azure managed identity to obtain access tokens for its MeF validation and transmission services. The browser does not receive those service credentials or perform the service authentication.
Validation and recorded filing outcomes
The Form 990-PF workflow validates XML against the selected IRS schema before packaging and transmission. Submission responses, rejection details, and status changes stay connected to the return. Exported 1099 batches retain fixed records so a later download reproduces the same batch.
These examples describe the ByteWish payroll and tax-form application. Its public ACH Toolkit has a different privacy model: NACHA files are read, checked, and built locally in the browser. See the browser-only file workflow.
Check the release.
Then ship it.
This site's release checks exercise application behavior and security as well as the pages people see. They run on our self-hosted CI runner, and a failed check stops the verified production deployment.
- Exercise the failure paths
- Unit, API, and browser tests check authentication, conversation isolation, duplicate requests, interrupted streams, image delivery, and signed Teams actions. Dependency auditing checks the packages that go into the application.
- Test the whole site
- The shared route list drives security, browser, axe, IBM, Impeccable, and mobile and desktop Lighthouse checks. New case studies enter the same suite as the homepage and contact page.
- Publish only reviewed files
- The build uses an explicit public allowlist. Research, signed contracts, internal instructions, source tooling, and private reports stay out of the website output.
- Keep secrets on the server
- Teams, AI, and monitoring credentials are supplied through server configuration. Preview and production have separate chat databases. Public browser code receives no Teams or model-provider keys.
- Connect results to a build
- Published reports include a date, tested scope, and source fingerprint. The verification checks that reports match the source before publishing the quality report.
- Deploy the checked output
- The main-branch workflow deploys the output it verified. It checks required production configuration before upload. Branch and pull-request checks do not run that production deployment.
NIST's Secure Software Development Framework provides a broader reference for secure development practices. These release checks show concrete parts of our implementation.
Know where
the conversation goes.
The public website's chat connects an AI assistant with our team. Its services and data path are visible here, so you can understand what happens when you send a message.
How website conversations are handled
- Website and chat backend
- Cloudflare Pages serves the website. Pages Functions handle chat requests, with conversation records and pictures in Cloudflare D1. Browser credentials remain in tab-scoped session storage.
- AI assistance
- Cloudflare Workers AI answers first, with our authenticated, self-hosted model service as a fallback. Conversation text is sent to the selected service with the site's published company information. Pictures are not sent to the language model.
- Human conversation
- When a person is needed, the backend delivers the conversation and its pictures to our Microsoft Teams support channel. Staff replies in the matching thread appear on the website. The AI stops answering that conversation after handoff.
- Monitoring and records
- Self-hosted Sentry receives application errors. Chat sessions expire, while copies delivered to Teams and follow-up email have their own retention. Read the privacy policy for storage and retention details.
Government information needs its own boundary
This is a public inquiry channel using commercial services. Send public project information here. For FCI, CUI, or other restricted records, contact our team first to agree on an appropriate exchange and the system's authorized data path.
For a regulated deployment, hosting, identity, model services, integrations, logging, and support access all need to be included in the requirements. We design that environment around the information it must protect.
Choose the environment.
Account for every service.
Hosting, identity, storage, integrations, and AI all belong in the architecture. We choose them around the information your system handles and the requirements it has to meet.
Hosting and service inventory
- Azure Government
- Our government-cloud engineering includes systems built for FedRAMP High requirements. We identify the in-scope services, application responsibilities, and operating controls for the agency's authorization boundary. Explore the government requirements.
- Azure Commercial
- We also build on Azure Commercial. ByteWish's MeF integration is a concrete example of Microsoft identity and server-side Azure managed identity connecting an application to protected services.
- Cloudflare
- This public website uses Cloudflare Pages and Functions. D1 stores website conversations. Cloudflare provides the public edge; the application adds its own credential, origin, request-limit, and data-access checks.
- Microsoft 365 and Teams
- Office 365 handles email. Website conversations handed to our team become a matching Teams thread. Staff replies are verified by the bot integration before they appear to the visitor.
- Model inference
- The website assistant uses Workers AI with an authenticated self-hosted model fallback. It answers public questions; it has no access to client applications or authority to make contractual commitments. Read the chat data path.
- Self-hosted monitoring
- Sentry provides application error monitoring in our own hosted environment. Public service availability is visible separately through the status page. Check service status.
This inventory describes our public website and confirmed engineering environments. Your project's architecture identifies its own services, information flows, access, retention, and compliance scope.
Ready for the
workday.
And after it.
Government services keep working after the office closes. We provide 24/7 support for the systems your people depend on.
View service status- Point-in-time backups
- Full point-in-time backups in Azure support recovery of your data.
- Access controls
- Full access controls protect who can reach and use your systems and data.
- Cloud infrastructure
- We work with Azure Government, Azure Commercial, and Cloudflare. We choose hosting to fit your system and requirements. We are an authorized Azure Government reseller. View our profile on Microsoft Marketplace
- Operational visibility
- We monitor public availability and use self-hosted Sentry to track application errors.
- Recovery planning
- Azure point-in-time backups provide a recovery path. We work through the required recovery point, recovery time, retention, and restore testing for your system as part of its operating requirements.
- Security issues and escalation
- Report a suspected vulnerability to [email protected]. Existing clients can reach support 24/7 and use their assigned emergency support contact for urgent incidents, including holidays. See support coverage.
Backups are the start.
Getting you working
is the goal.
Your staff need a way to keep serving people when something goes wrong. Our Azure point-in-time backups and 24/7 emergency support provide a foundation. The recovery plan connects that foundation to your actual work.
For your system, we work through the decisions below: what must keep running, who takes action, how data comes back and how everyone knows it is safe to resume.
Download the security review checklist (CSV)Business continuity: keep essential work moving
A continuity plan starts with the service people need, including deadlines, critical transactions, integrations and the staff who depend on them. It needs a workable fallback while the system is being restored.
Decisions to make
Which functions take priority; who can declare an incident; alternate ways to accept work; staff and public communications; and how work recorded during an outage will be reconciled.
Evidence to review
A named owner, an approved continuity plan, a current contact tree and the outcome of a tabletop exercise using a realistic disruption.
Disaster recovery: bring the whole system back
A database restore is one step. A usable recovery also needs the application, identity, configuration, secrets, files and integrations to work together.
Decisions to make
Recovery order and dependencies; who has emergency access; which backups and deployment versions to use; and who can approve returning the system to service.
Evidence to review
A versioned recovery runbook, dependency inventory and restore record showing the actual steps, elapsed time, checks performed and follow-up fixes.
Alternate processing and storage
Redundancy needs to cover the failure you are planning for. A second copy in the same region answers a different question from a recovery environment outside that region.
Decisions to make
Region or site failure; backup storage redundancy; alternate capacity; data residency; independent access to keys and configuration; and the route back to normal operations.
Evidence to review
The selected service configuration, approved locations, architecture diagram and the result of a failover or alternate-site recovery exercise. The choices depend on your deployment and its authorization boundary.
Recovery targets that mean something
The recovery point objective sets how much recent data can be lost. The recovery time objective sets how soon the service must be restored. Both need to match the consequences of an outage.
Decisions to make
Targets for each critical service; backup frequency and retention; restore capacity; and what happens when a target is missed. Record these in the operating agreement.
Evidence to review
Agreed RPO and RTO, backup configuration and measured recovery results. Compare the actual restored data and elapsed time with the agreed targets.
Restore testing and return to service
A restored system should be checked before staff rely on it. That includes records, attachments, permissions, calculations and the workflows that move work between departments.
Decisions to make
Exercise frequency; a protected test environment; representative validation cases; record counts and reconciliation; client acceptance; and cleanup of restored test data.
Evidence to review
The exercise date, recovery point, validation results, unresolved issues and approval to resume. Retest material changes to the recovery path.
Incident response and holiday coverage
Existing clients can contact their assigned emergency support staff at any hour, including holidays. A suspected security issue can also be reported to [email protected].
Decisions to make
Severity and escalation; containment authority; evidence preservation; legal and client notification responsibilities; communication channels; and recovery approval.
Evidence to review
The incident runbook and contact tree, an exercise or incident timeline, and the follow-up actions. Agree notification and response obligations for the engagement rather than relying on a generic promise.
Planning references: NIST contingency planning guidance and Microsoft's Azure SQL recovery checklist. These explain the planning and platform options; the configuration and exercise records establish what is in place for your system.
A record of staying available.
100% monitored availability for www.developingtoday.net and sdlegislature.gov, April 22, 2022 through September 28, 2026.
Better Stack checked both public endpoints every ten minutes. South Dakota LRC hosts its system following our recommendations.
See the availability record Your data.
Your source code.
Your control.
You own your source code and data. Full end-user exports and a full-featured OpenAPI specification are standard in our systems.
Ownership and deliveryPrivacy in practice.
This website uses no advertising or analytics scripts. Our privacy policy explains hosting, operational information, self-hosted error monitoring, and how we handle inquiries.
Read the privacy policyThe whole
security picture.
Application security is only part of the job. A system also depends on the people, devices, suppliers, recovery arrangements and operating controls around it.
Open a topic to see current practices, public evidence and the details to establish for your system.
Talk with us about your security requirementsCompliance and independent assurance
We engineer for demanding government requirements, including FedRAMP High workloads on Azure Government. Our standards guide separates application controls, inherited cloud controls and the assessment each program requires. Explore the standards and assessment requirements.
Review coverage
SOC 2 Type II; SOC 3; FedRAMP; GovRAMP (formerly StateRAMP); TX-RAMP; AZRAMP; CMMC; NIST SP 800-53; NIST SP 800-171; HIPAA; GDPR; CCPA; CPRA; NIST AI RMF; accessibility conformance and VPAT/ACR.
For your system
Framework-specific control implementation and evidence; independent reports and program status must be verified for the named system.
Application, product and data security
Our published website checks include ZAP, Observatory, browser security tests and Subresource Integrity. ByteWish shows organization permissions, encrypted financial fields and protected IRS submission workflows. Inspect financial application safeguards.
Review coverage
Application penetration testing; audit logging; integrations; data access; data classification; encryption at rest; access monitoring; data backups.
For your system
Independent penetration tests, logging coverage, key management, classification and privileged access evidence for each application.
Infrastructure, networks and continuous monitoring
Azure Government, Azure Commercial and Cloudflare support our deployments. Self-hosted Sentry captures application failures. Public availability monitoring and dated website security scans make results inspectable. Open the measured security results.
Review coverage
Cloud providers; anti-DDoS; web application firewall; bot detection; SIEM; intrusion prevention; automated compliance monitoring; SSL grades; external security ratings.
For your system
System-specific edge rules, log destinations, alert response, network controls and monitoring coverage. An error tracker is distinct from a SIEM.
Identity, devices and corporate security
Full access controls are part of the systems we deliver. The financial application uses Microsoft identity, organization permissions, managed service identity and passkey assertions for sensitive workflows. Review identity and application controls.
Review coverage
Access controls; access logs; password management; staff MFA; endpoint protection; anti-malware; disk encryption; email protection; asset inventory; physical and environmental security.
For your system
Staff MFA, device enrollment and encryption, endpoint protection, email controls, account lifecycle, asset ownership and physical access evidence.
Support, incident response and recovery
Clients have 24/7 assigned emergency support, including holidays. Full Azure point-in-time backups support recovery. Office closures do not remove on-call coverage. See support coverage and escalation.
Review coverage
Designated response personnel; incident reporting; security operations coverage; business continuity; disaster recovery; alternate processing and storage; RTO; RPO; risk and impact levels.
For your system
Recovery targets, restore exercises, alternate-site design, incident runbooks, communications and system-specific responsibilities.
Privacy, legal and suppliers
Clients own their source code and data. Our privacy policy explains the website's providers, browser storage, chat and error monitoring. End-user exports and OpenAPI specifications keep information accessible. Read the website data practices.
Review coverage
Privacy notices; cookies; subprocessors; customer agreements; data processing agreements; service levels; cyber insurance; data retention; data ownership.
For your system
The applicable contract, processing terms, service levels, insurance evidence, supplier responsibilities and retention for the engagement.
AI and human oversight
The website assistant answers from approved public information and can hand a conversation to our team in Teams. It has no access to client applications and cannot agree to contract terms. Follow the chat and AI data flow.
Review coverage
AI overview; AI features; model providers; data use; human handoff; NIST AI risk management.
For your system
Model access, data boundaries, output evaluation, human oversight and incident handling for the specific AI feature.
People, policy, ESG and change management
This website's release pipeline checks every redesigned page on self-hosted runners. Its published reports identify the tested build. Application changes can be checked against working browser, API, accessibility and security tests. See the release checks.
Review coverage
Security policies; employee privacy training; security awareness; phishing training; anti-bribery and corruption; risk management; asset management; change approval; security advisories and trust updates; environmental, social and governance (ESG) practices.
For your system
Approved policies, training records, risk and asset registers, change responsibilities, policy review dates and security communications. Environmental and social commitments need their own documented practices and evidence.
Controls, assessments and formal assurance.
Control assessments identify the system, requirement, implementation, evidence, reviewer and date. Independent audits and program approvals add their own assessment requirements. SOC reports come from an independent CPA examination; FedRAMP, GovRAMP and other program designations apply to the assessed offering.
See how the frameworks apply. Our Azure Government engineering capability and this website's published scans each have their own defined scope.
Talk to the people
building your system.
Bring your security requirements, questionnaire or current assessment. We'll work through the application, its cloud boundary and its operating responsibilities with you.
Arrange a security reviewUse our checklist to record the control, evidence, system, owner, review date and follow-up. It covers the application and the organization operating it.
Download the security review checklist (CSV)- Application and engineering
- Access-control test results, audit trails, encryption and key management, API boundaries, dependency review, vulnerability findings and fixes.Discuss application security evidence
- People and operations
- Staff identity and MFA configuration, device and asset controls, training records, incident responsibilities, recovery arrangements and supplier access.Discuss operational security evidence
- Contracts and assurance
- Processing terms, retention, service levels, insurance, framework assessments and any applicable independent reports. Establish which evidence is public, which needs a secure review and what remains to be completed.Discuss contracts and assurance
Expect more
from your software.
Share your current application's public address or a report from your vendor. We'll talk through the results and what you want the system to do better.
Let's compare your applicationReport a security issue
Send the affected address, what you observed, and steps to reproduce it. Contact us first to arrange a secure way to share sensitive details.
[email protected] 605-610-2992