Security & Trust

• 1: What SWS Installs in PeopleSoft
• 2: Code & Supply Chain
• 3: Authentication & Access
• 4: Data Handling & Logging
• 5: Deployment & Operations
• 6: Compliance & Vendor

%%{init: {"flowchart": {"htmlLabels": true, "padding": 16, "nodeSpacing": 50, "rankSpacing": 60}}}%%
flowchart TD
    APP["psLens app<br/>(dedicated instance per customer)"]
    SWS["SWS framework<br/>(installed in your PeopleSoft environment)"]
    DB[("PeopleSoft database<br/>(read-only)")]

    APP -- "HTTPS + basic auth<br/>(token in config.yaml or env var)" --> SWS
    SWS -- "psoftQL, scoped to<br/>whitelisted tables" --> DB

    classDef ps fill:#e8f4fd,stroke:#0d6efd,stroke-width:2px,color:#000
    classDef ext fill:#fff5e6,stroke:#fd7e14,stroke-width:2px,color:#000
    class APP ext
    class SWS,DB ps

1 - What SWS Installs in PeopleSoft

The SWS (Secure Web Services) framework is the PeopleSoft-side component psLens queries through. This page lists what installing it actually changes in your environment, so the person approving the change can see the full footprint before anything is migrated. The authoritative installation guide lives at sws.books.cedarhillsgroup.com; this page is the summary for a security review.

The Install in One Paragraph

SWS is delivered as a standard App Designer project. You import it into a development environment first, test it there, and migrate it to TEST and PROD through your normal change-management path, the same way you move any other project. There is no installer, no agent, and no software on the database server. Plan for under an hour of PeopleSoft admin time for the first environment.

What the Project Contains

Roughly 100 PeopleSoft objects, all namespaced with the CHG_ prefix (C_ for records):

• 9 records for configuration and logging, including the whitelist tables described below
• 32 fields supporting those records
• 4 pages for administration and testing
• 6 application packages containing the framework’s PeopleCode
• 2 service operations: CHG_SWS_GET and CHG_SWS_PSOFTQL_POST
• 2 roles: CHG_SWS_ADMIN (setup pages) and CHG_SWS_USER (API access)

The full object manifest is in the SWS installation docs. The project ships with sample data for testing; the SWS docs are explicit that sample data is not meant for production systems.

Security Objects and the Service Account

psLens connects as a PeopleSoft operator you create for it (for example PSLENS_API). That account:

• holds the CHG_SWS_USER role, which grants access to the API and nothing else
• authenticates to the service operations with HTTP basic auth over HTTPS
• is an ordinary PeopleSoft account, so your existing controls apply: lock it in PSOPRDEFN and all psLens access stops immediately

No new database users are created. Nothing connects to the database directly; every query runs through the application server like any other Integration Broker request.

The Whitelist

SWS only answers queries against records listed in PS_C_SWS_REC_WL, scoped to the permission list of the calling API user. A query that references anything off-list is rejected before it reaches the database.

psLens needs roughly 130 PeopleTools metadata records whitelisted. The list is published in two places: the Reference page describes each record and which psLens feature uses it, and Whitelist Tables has the SQL inserts you run during installation. You run those inserts yourself, which means you review every record psLens will ever be able to read, and you can narrow the list at any time.

Integration Broker Setup

The two service operations come with routing definitions and handlers and run on your existing Integration Broker gateway. No new gateway, listening connector, or node is required. Because the traffic is ordinary REST service-operation traffic, it is visible in your IB monitoring tools alongside every other integration.

What to Tell Your DBA

• All queries are reads against PeopleTools metadata tables on the whitelist. SWS has no write path for psLens to call.
• Query volume is driven by on-demand page views plus a configurable alert interval (default every 5 minutes). See the load FAQ for the breakdown.
• There is nothing to install or configure at the database layer. The change is entirely PeopleTools objects plus whitelist rows.

Questions

If your security team needs answers in writing before approving the install (object-by-object review, role configuration, whitelist scoping), raise it on the demo call or email chris.malek@cedarhillsgroup.com.

2 - Code & Supply Chain

This page is for security reviewers who need to understand what is running inside psLens before approving its deployment. It covers four questions:

1. What code is actually running?
2. Can we audit it?
3. How is it built and shipped?
4. How are vulnerabilities found, disclosed, and fixed?

If you’re looking for the higher-level read-only / whitelist story, start with Security & Trust and come back here for the detail.

1. What’s Inside the Image

psLens is a single Go binary plus an embedded NATS server, packaged as a multi-stage Docker image distributed from ghcr.io/cedarhillsgroup/pslens. There is no separate database, message broker, or external worker process; one container is the whole application.

Runtime stack

There is no embedded browser, no third-party telemetry SDK, no analytics tracker. The full dependency list is go.mod in the source tree.

Base image

The runtime stage is debian:bookworm-slim with ca-certificates. No shell access is required for normal operation; psLens runs as PID 1.

2. Source Availability and Review

psLens is closed-source. The source tree is not published publicly.

For customers who need to review the code: Cedar Hills Group offers a read-only source review under NDA as part of the procurement process. Mechanics (on-site, screen-share, time-boxed access) are agreed during contracting. Reach out via the contact page to arrange.

This is the same model used by most enterprise PeopleSoft tooling: the binary is yours to run, the source is reviewable under contract, redistribution is not granted.

3. Build and Distribution

Build pipeline

The release pipeline injects the version, commit SHA, and ISO-8601 build timestamp into the binary at compile time via Go ldflags. You can read them back from any running instance via /healthz and the startup banner in container logs. Useful for confirming exactly which build a customer is running.

What we do today

• Traceable builds. Every image embeds the git SHA and build timestamp in its label and binary; you can map any running container back to the exact source commit that produced it.
• Pinned tag flavors. Production customers pin to vMAJOR.MINOR (or exact vMAJOR.MINOR.PATCH) so a docker compose pull never surprises them with a major-version change. See Deployment Options for the tag flavors and recommended pinning.
• Private package distribution. GHCR access is gated by per-customer read-only fine-grained personal access tokens.

What we don’t do yet (roadmap)

• Image signing with cosign. Planned. Once landed, every published tag will carry a sigstore-verifiable signature and you’ll be able to verify provenance with cosign verify.
• SLSA build provenance attestation. Planned alongside cosign.

4. Dependency Management

Today

• go.mod is the single source of truth; all dependencies are pinned by version and content hash (go.sum).
• Automated scanning. We run govulncheck daily and on every push/PR in our GitHub Actions CI pipeline to verify there are no known exploitable vulnerabilities in our dependencies.
• Dependency monitoring. Dependabot is enabled to track Go modules, GitHub Actions, and Dockerfile base images, raising automated pull requests for updates.
• The dependency footprint is intentionally narrow (see the table above); Go standard library does most of the work.

If your security policy requires SBOM artifacts as part of vendor onboarding, ask on the demo call. We can generate a CycloneDX or SPDX SBOM from a tagged build on request.

5. Vulnerability Disclosure and Patching

Reporting a vulnerability

Email security@cedarhillsgroup.com. Please include:

• Affected version (the git SHA from /healthz is most precise)
• Reproduction steps or proof-of-concept
• Your assessment of severity (CVSS or descriptive)

We commit to:

• Acknowledgement within 1 business day of receipt.
• Coordinated disclosure. We will agree a disclosure window with the reporter before publishing details.
• Crediting researchers in the release notes unless they prefer otherwise.

Patch SLA

Specific patch targets (business days for Critical, High, Medium) are disclosed during contracting.

When a fix ships, it goes out as a patch release in the same vMAJOR.MINOR stream you’re already pinned to. docker compose pull && docker compose up -d picks it up. Critical fixes are also announced by email to deployment contacts.

Subscribing to release notes

Release notes are published as GitHub Releases on the source repo. Deployment contacts are notified by email for any release with a security note.

6. What Reviewers Usually Ask

“Is the binary statically linked?” Yes. Go produces a static binary; no system library version drift.

“Does it phone home?” No. There is no outbound connection from a running psLens instance other than (a) to your SWS endpoint and (b) to your SMTP server if you’ve enabled magic-link auth. No telemetry, no update checks, no license-server callbacks.

“What user does it run as inside the container?” Confirm the current default with us on the demo call. Recommendation for self-hosters regardless: run with --user 1000:1000 and a read-only root filesystem; only /data needs to be writable.

“How big is the attack surface?” One HTTP listener (default port 8080 or whatever you configure), serving HTML and Server-Sent Events. No raw socket listeners, no UDP, no message-queue ingress, no plugin loader.

Related

• Authentication & Access. How the HTTP listener authenticates users.
• Data Handling & Logging. What’s stored, how it’s encrypted, what’s logged.
• Deployment & Operations. Backup, upgrade, sizing.
• Compliance & Vendor. SOC 2 posture, sub-processors, DPA.

3 - Authentication & Access

This page covers how end users authenticate to psLens, what access controls exist (and which deliberately don’t), and how to front psLens with your existing identity provider today.

For SSO, see SSO Today.

1. How Users Log In Today

psLens ships with optional email magic-link authentication. It is off by default in the shipped config.yaml and must be turned on for production deployments.

When auth.enabled: true:

1. User visits any psLens URL → redirected to /login.
2. User enters their email address.
3. psLens emails a one-time verification code to that address (only if the address is on the configured AuthorizedUsers allowlist).
4. User enters the code at /verify-code.
5. Session created in NATS KV, identified by an HTTP-only psLens_auth cookie.

There are no end-user passwords for psLens to store, leak, hash, or rotate.

Disabling auth entirely is supported only for sandbox or trusted-network deployments. The shipped config defaults to disabled so a first-time installer can get to a working UI quickly. Flip it on before exposing the instance.

2. The Deliberate Scope Decision: No In-App RBAC

psLens has no role-based access control inside the application. Every authenticated user sees the same set of metadata, can run the same reports, and can browse the same PS objects.

This is intentional, not an oversight:

• psLens is read-only. It cannot modify PeopleSoft. The worst an authenticated user can do is read metadata.
• The query surface is whitelisted on the PeopleSoft side by the SWS framework. Even psLens itself cannot query anything off-list. See Security & Trust.
• The access boundary therefore lives at who is on the AuthorizedUsers list, not at “what role does this user have inside psLens?”. If a user shouldn’t see PS metadata at all, they shouldn’t have a psLens login.

For most customers, the population of people who need psLens (PS developers, sec admins, sys admins, business analysts doing audit work) is small and homogeneous. Adding in-app roles would create configuration overhead without changing the actual blast radius.

If your security policy requires per-user authorization decisions at the application layer, raise it on the demo call. The reverse-proxy patterns below can enforce this without requiring psLens itself to grow an RBAC model.

3. SSO Today: Reverse Proxy

The recommended pattern for any production deployment is to front psLens with a reverse proxy that handles SSO, and turn off the built-in magic-link layer. This delegates authentication to the IdP you already trust.

Common setups:

The pattern is the same in every case:

1. The reverse proxy terminates TLS, authenticates the user against your IdP, and only forwards authenticated requests to psLens.
2. psLens trusts the proxy (binds to a private network or listens on 127.0.0.1).
3. auth.enabled: false in psLens config. The proxy is the identity boundary.

Cross-link: the TLS termination patterns in Deployment Options cover the same reverse proxies and explain how to wire them up; this page is the identity-layer companion.

What the proxy can do that psLens RBAC could not: enforce group membership (“only the psoft-admins group in Okta”), require MFA, enforce conditional access policies (managed device, geo, time-of-day), and write to your existing IdP audit log.

4. Native SSO on the Roadmap

Native OIDC support inside psLens is planned. No committed date. This will let customers who don’t want a reverse-proxy hop configure their IdP directly in config.yaml.

We are deliberately not promising native SAML. The reverse-proxy patterns above already cover SAML; native OIDC closes the more common gap.

Until native SSO ships, reverse-proxy SSO is production-ready. It is the recommended deployment pattern for every customer with an enterprise IdP.

5. Session Management

A built-in admin-facing “kill all sessions” UI is on the roadmap. Today the NATS CLI path above is the supported route.

6. What Reviewers Usually Ask

“Can we require MFA?” Yes, by fronting with a reverse proxy that enforces MFA at the IdP layer (any of the proxies above). Magic-link auth on its own is single-factor (control of the email inbox).

“Where does the user email come from on the SWS side?” psLens authenticates its own users via magic-link or reverse-proxy SSO. Those are the people using the psLens UI. psLens authenticates to PeopleSoft via the SWS service account (basic auth, see Code & Supply Chain). The two identity domains are independent. Your psLens users do not need PS accounts.

“Can we revoke a user instantly?” Yes. Remove them from AuthorizedUsers and restart; their next request fails. With reverse-proxy SSO, revoke them at the IdP and they lose access on the next request, no restart needed.

“Does psLens store passwords?” No end-user passwords. The only password-shaped secret psLens holds is the SWS service-account password used to call PeopleSoft, encrypted at rest with AES-256-GCM. See Data Handling & Logging.

Related

• Code & Supply Chain. What runs in the auth code path.
• Data Handling & Logging. Session storage, cookie flags, login logging.
• Deployment & Operations. Reverse-proxy TLS patterns that pair with reverse-proxy SSO.

4 - Data Handling & Logging

This page is for compliance reviewers and DPOs who need a precise answer to “what data does psLens hold, where, and for how long?”, and for security teams checking encryption and audit-trail posture.

For PII handling, jump to Personal Data (PII).

1. What psLens Stores

psLens persists three categories of data, all inside the customer’s own dedicated instance. There is no shared multi-tenant backend.

That is the complete persistent footprint. Everything else (query results, page renders, search hits) is generated on demand and not written to disk.

2. What psLens Does NOT Store

• PeopleSoft business data. Employee records, payroll, financial transactions, HR data, customer records, journals, vouchers. None of it. Reports summarize at runtime and discard the raw rows.
• Database passwords in cleartext (when PSLENS_MASTER_KEY is set).
• End-user passwords. psLens uses magic-link or reverse-proxy SSO; there are no user passwords to store.
• Logs on disk. Logs go to stderr; your container runtime decides what to do with them.
• Telemetry, analytics, or usage data shipped back to Cedar Hills Group. psLens does not phone home.
• Client-side cached data. Nothing is cached in the browser. No writes to LocalStorage, SessionStorage, or IndexedDB; close the tab and there is nothing left.

3. Personal Data (PII)

The answer is more nuanced than “no PII”.

psLens does not store PeopleSoft user PII. No persistent table or KV entry contains employee or operator records.

psLens does process PeopleSoft user PII at request time. When a user opens a search for Users, Operator IDs, or related security objects, psLens queries PeopleSoft, renders fields like OPRID, OPRDEFNDESC, EMAILID, and EMPLID in the browser, and discards the rows after the response. The data passes through psLens memory; it is not written to NATS, disk, or any log.

What this means for GDPR / CCPA / similar:

• psLens acts as a processor of this data while a query is in flight.
• The controller is the PeopleSoft owner (the customer).
• A DPA is available on request. See Compliance & Vendor.
• Subject access / erasure requests are handled at the PeopleSoft source of record. psLens has nothing to delete because it has nothing persisted.

If your jurisdiction or policy requires that even transient processing be scoped, the AuthorizedUsers allowlist and the SWS table whitelist give you two layers of control over who can trigger such a query at all.

4. Encryption

In transit

The SWS endpoint URL is HTTPS in every supported deployment. If you have a network where the PS server is reachable only over HTTP, raise it on the demo call. Running psLens over plaintext to PS is not a supported posture.

At rest

Master key management:

• Required (and enforced at startup) when PSLENS_ENV=production.
• Stored as a 64-char hex string (32 raw bytes) in the PSLENS_MASTER_KEY env var. On fly.io: fly secrets set PSLENS_MASTER_KEY=.... In Docker Compose: .env file with 0600 permissions, or an external secret manager.
• Back it up out of band. Losing the master key means encrypted DB credentials in NATS KV become unreadable; you’d need to re-enter them.
• Self-service rotation. Generate a new key and trigger rotation directly from the Settings UI (Advanced page). The server decrypts all stored credentials using the old key and re-encrypts them with the new key in NATS KV. The operator must update the PSLENS_MASTER_KEY environment variable in the deployment configuration to match the new key before the container restarts.

5. Audit Logging

What psLens logs today

The request ID flows through every log line tied to a request, so you can correlate a UI action to its server-side handler chain.

Logs are written to stderr only. psLens does not write logs to disk. Your container runtime decides what happens next: typically piped to your Docker logging driver, your systemd journal, your fly.io log stream, or your K8s log shipper. Send them to your SIEM via the same standard mechanism you use for any container workload.

Where the user-action audit actually lives today

Because psLens is read-only, the question “who looked at what PS data, when” has its authoritative answer on the PeopleSoft side. The SWS framework logs every query it accepts, including the OPRID of the SWS service account, the SQL it ran, and the timestamp. That is the audit trail that matters for “did someone see employee X’s record”.

What psLens contributes:

• The HTTP request log (above) ties an authenticated psLens user to a specific page hit, and the page hit corresponds to a known set of SWS queries.
• Correlation across the two logs uses the request ID on the psLens side and the timestamp + query pattern on the SWS side.

The gap and the roadmap

Today, psLens does not write a structured per-user “action” audit log. For example, {user: alice, action: viewed, object: PSRECDEFN PS_VOUCHER, at: 2026-05-21T14:32Z}. The HTTP request log is close to that but is operational logging, not an audit artifact.

Roadmap: add a first-class user-action audit log written to a NATS KV bucket with configurable retention, exportable to your SIEM. Targeted to land alongside native SSO. No committed date.

If a customer needs a richer audit story today, the recommended interim is: enable auth.enabled, ship the HTTP request log to your SIEM, and correlate with the SWS-side audit. Cedar Hills Group can help with the correlation queries.

Retention

psLens retains structured logs only in your container runtime’s log stream. Retention is whatever you configure there. No psLens-managed log retention policy exists; we deliberately stay out of that decision so it aligns with your existing log-retention SLAs.

6. What Reviewers Usually Ask

“Where is the data physically?” In your dedicated psLens instance. Managed deployments live in the fly.io region you choose at provisioning. Self-hosted: wherever you run the container. There is no shared backend.

“Can you delete all data for a customer on request?” Yes, by removing the deployment. Because all customer-specific state lives in the per-customer container’s /data volume, deletion is fly apps destroy or docker compose down --volumes. There is no other location to scrub.

“Do you encrypt the entire volume?” Application-level encryption covers credentials. Volume-level encryption is the customer’s choice. On fly.io, volumes are encrypted at rest by default; on your own infrastructure, use LUKS / EBS encryption / equivalent.

“Do you have an SBOM?” Available on request for any tagged build. See Code & Supply Chain.

Related

• Code & Supply Chain. What’s running in the code paths that touch data.
• Authentication & Access. Session storage details.
• Deployment & Operations. Backup and restore for /data/nats and /data/projects.
• Compliance & Vendor. DPA, sub-processors, residency.

5 - Deployment & Operations

This page consolidates the operational story that an IT or DBA reviewer needs in one place. It overlaps with Installation and Deployment Options; those are the how-to references, and this page is the what-to-expect security-review companion.

1. Deployment Model

• One container per customer. Each customer gets a dedicated psLens deployment: separate process, separate NATS instance, separate /data volume.
• No shared multi-tenant backend. There is no Cedar Hills Group SaaS plane that customer instances talk to. Your psLens instance talks to your PeopleSoft and (optionally) your SMTP, and that is it.
• Two hosting options:

  Mode	Operated by	Where it runs
  Managed	Cedar Hills Group	fly.io, in the region you choose at provisioning
  Self-hosted	You	Docker, docker-compose, Kubernetes, or systemd on a Linux VM. Your cloud, on-prem, or air-gapped.

The choice is reversible. You can start managed and migrate to self-hosted (or vice versa). The data volume is portable and the configuration travels.

2. Network Requirements

Inbound

Outbound

This means psLens runs cleanly behind strict egress filtering. Allow it the SWS hostname (and SMTP host if applicable) and deny everything else.

TLS termination

Cross-link: Deployment Options → TLS compares 6 patterns (native cert, Let’s Encrypt, Caddy, nginx, Traefik, Tailscale Serve). Pick the one that matches your existing edge.

3. Sizing

Recommended minimums:

For deployments handling many concurrent users or running heavy reports, scale up to 2 vCPU / 1 GB RAM. psLens is a single Go process; vertical scaling is the path, and there is no clustering model today.

4. Backup and Restore

What to back up

Suggested cadence

• Nightly tarball of /data/nats and /data/projects to your backup target.
• 14–30 day retention for daily snapshots; longer if your audit policy requires.
• Master key stored separately (so a single-system compromise can’t yield both).

Example backup script (Docker host):

#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y%m%dT%H%M%SZ)
docker run --rm \
  --volumes-from pslens \
  -v "$BACKUP_DIR":/backup \
  alpine \
  tar czf "/backup/pslens-${TS}.tar.gz" /data

Restore

1. Stop the container.
2. Restore the tarball into a fresh /data volume.
3. Ensure PSLENS_MASTER_KEY matches the key that encrypted the credentials.
4. Start the container.

5. Disaster Recovery

Today’s posture:

• For self-hosted: DR is whatever your existing container DR posture is. psLens fits the same pattern as any small stateful Go service: restore the data volume, restart.
• For managed (fly.io): redeployment is fast because all state fits in one volume. Cedar Hills Group operates the deployment; RTO/RPO targets for managed deployments are disclosed during contracting.
• No multi-region replication of psLens state today. The single-customer scope makes this rarely worth the complexity, but if your contract requires it, raise it on the demo call.

If you need a higher DR posture than this, the answer is usually “self-host and use your existing DR tooling for the volume.” Cedar Hills Group can help structure that.

6. Monitoring

What ships today

• GET /healthz returns 200 OK if the process is alive. Liveness check only; no readiness signal beyond startup completion.
• Structured slog to stderr for every request and every error. Ship to your SIEM via your container runtime’s log driver.
• Startup banner in logs: version, commit SHA, build timestamp. Useful for confirming an upgrade landed.
• Connection-status UI inside psLens shows live SWS reachability for each configured database.

What doesn’t ship today

• No Prometheus /metrics endpoint. Planned. No committed date.
• No built-in alerting, in the sense of “psLens noticing it has a problem and notifying you.” That is your monitoring system’s job, fed by /healthz and the log stream.

Recommended wiring for a customer environment:

7. Upgrades and Rollback

Pin production to a vMAJOR.MINOR tag. To upgrade:

docker compose pull
docker compose up -d

The data volume survives the restart. Schema migrations on the NATS KV layer (if any) run automatically on first start of the new version.

To roll back, pin to the prior vMAJOR.MINOR.PATCH tag, docker compose up -d. Downgrade compatibility within a vMAJOR.MINOR is guaranteed; across major versions, check the release notes.

Breaking change contract: breaking changes only land in major version bumps and are called out explicitly in release notes. Patch and minor releases preserve config compatibility.

Cross-link: Deployment Options → Image Tags for the full tag-flavor table.

8. Multi-Environment Support (DEV / TEST / PROD)

A single psLens instance can be configured to connect to multiple PeopleSoft databases (DEV, TEST, PROD, demo) via entries in config.yaml. The database selector appears on every search and report page.

This is usually the right deployment shape: one psLens instance per psLens user community, configured to see every PS environment that community needs. It is rarely useful to run multiple psLens instances unless those communities have non-overlapping access requirements that need to be enforced at the network layer.

9. DBA Concerns: What psLens Does to Your PS Server

For PeopleSoft admins who need to sign off on the load profile:

The PS-side audit trail (SWS query log) captures every query psLens issues with timestamps and the SWS service-account OPRID. If psLens is misbehaving, that log shows what it actually did.

Cross-link: Installation → Whitelisting Tables for the full list and SQL.

Related

• Installation. First-time setup with copy-pasteable commands.
• Deployment Options. TLS, image distribution, configuration.
• Data Handling & Logging. What’s in /data/nats and how it’s encrypted.
• Compliance & Vendor. Sub-processors, residency, contract.

6 - Compliance & Vendor

This page is for procurement, legal, and vendor-risk reviewers. It states current posture plainly, including where certifications do not yet exist.

If you’re filling out a vendor questionnaire (SIG, CAIQ, custom), the Security Questionnaires section is the right place to start.

1. SOC 2 — Current Posture

Cedar Hills Group is not SOC 2 certified today. Certification is on the roadmap. No committed date.

In the interim, this site documents the controls a SOC 2 Type II report would cover, so a reviewer can map them to their own framework. The relevant Trust Service Criteria and where they’re addressed:

This map is not a SOC 2 report; it is a vendor-side description of controls. We will fill out your SIG, CAIQ, or in-house questionnaire and return it (see below).

2. GDPR and Personal Data

• psLens does not persist PeopleSoft user PII. There is no stored copy of employee, operator, or HR records.
• psLens does process PeopleSoft user PII at request time when users search Users / OPRIDs / EMPLIDs. Data is rendered to the browser and discarded.
• For GDPR purposes, the customer (the PeopleSoft owner) is the controller; psLens / Cedar Hills Group is the processor.

What this means in practice:

For CCPA, the answer mirrors GDPR: psLens does not “sell” data, does not retain data, and processes only at request time.

3. Data Residency

There is no shared multi-tenant backend, so there is no place for data to “leak” into a different region by accident.

4. Sub-Processors

The sub-processor list depends on the deployment mode you choose:

Self-hosters who don’t use magic-link auth have no Cedar Hills Group sub-processors at runtime. You run the infrastructure end to end.

The specific SMTP provider used by default for managed deployments is named during contracting so it can be reviewed against your vendor list.

Notification of sub-processor changes is provided in the DPA and in writing to deployment contacts.

5. Contract, SLA, and Termination

6. About Cedar Hills Group

Cedar Hills Group is a PeopleSoft consultancy. The same team that built the SWS framework (the bounded REST API that psLens uses to talk to PeopleSoft) builds psLens, so the access path psLens uses is one we control end to end.

What this means for vendor reviewers:

• The team has run real PS environments for real customers and built psLens out of that operational need.
• Cedar Hills Group is reachable and contactable; this is not a self-service SaaS where you can’t get a human on a call. See contact.

More on the company: cedarhillsgroup.com.

7. Business Continuity: What Happens If Cedar Hills Group Goes Away

A fair question in any vendor review:

• You keep the Docker image you’re running. GHCR can rotate tokens or change ownership; the image you’ve already pulled keeps working. Pin to a specific vMAJOR.MINOR.PATCH and you have an indefinite-life binary.
• Self-hosting works without Cedar Hills Group infrastructure. No runtime callback, no license check, no cloud control plane. If our domain disappeared tomorrow, every self-hosted instance keeps running.
• Managed deployments could be migrated to self-hosted. All state is in the per-customer /data volume. Cedar Hills Group commits to providing the volume and configuration on termination so you can restart it on your own infrastructure.
• Source escrow. Available on request for enterprise contracts.

Together: a binary you already hold, a portable data volume, and (on enterprise contracts) source escrow. That is the answer to “what is our exposure if the vendor goes away.”

8. Security Questionnaires

We complete the following questionnaires on request as part of an evaluation:

• SIG Lite. Standard short form.
• SIG Core. Long form.
• CAIQ (Cloud Security Alliance). For cloud-shape reviews.
• Your own custom questionnaire. Preferred, since it asks what your team actually cares about.

To kick this off, email chris.malek@cedarhillsgroup.com with the questionnaire attached, or raise it on the demo call.

For questions that are common across questionnaires, the answer often already lives in one of the pages below. Cross-referencing those pages in your questionnaire response is encouraged.

Related

• Security & Trust. The higher-level picture.
• Code & Supply Chain. What code runs, dependency posture.
• Authentication & Access. Login model, SSO.
• Data Handling & Logging. PII, encryption, audit.
• Deployment & Operations. Backup, residency, DR.