Solar Software Security: 12 Data-Control Questions

A solar software demonstration usually shows the happy path. An address enters, a roof appears, modules move, modeled output updates, and a proposal leaves the screen. Security diligence begins where that demonstration stops. Which customer records entered? Who can reopen them? Which administrator can change access? What survives an export? What happens if the provider, integration, or buyer account is unavailable?

Those questions are not reasons to distrust cloud software. They are how an EPC converts a broad claim such as “secure” or “your data” into a reviewable operating boundary. The general solar software buying interview asks whether a product fits the workflow, cost, implementation, and exit. This guide stays narrower and deeper: security evidence, privacy context, control of project records, and continuity after change or termination.

NIST Cybersecurity Framework 2.0 provides general cybersecurity risk-management context for organizations. It is not a certificate for a vendor and does not decide which platform an EPC should buy. Use it to organize the conversation, then require evidence that matches the service, configuration, users, data, integrations, and consequences in scope.

This is a desk-research diligence method, not cybersecurity, privacy, legal, contract, records, insurance, engineering, utility, regulatory, or incident-response advice. Requirements and risk decisions depend on the company, data, service, agreement, market, and intended use. Qualified owners must review the current evidence and contract.

What must solar software security diligence decide?

Solar software security diligence must decide whether a defined service, configuration, and operating model fit the buyer’s accepted risk and data-handling requirements. It should identify blocking gaps, customer and vendor responsibilities, contract dependencies, compensating controls, and exit conditions. The outcome may be approve, restrict, remediate, pilot, defer, or reject rather than one universal security score.

Begin with the intended use. A platform used only for public marketing imagery has a different exposure from one holding homeowner identities, utility bills, site photographs, interval data, designs, financial scenarios, contracts, or credentials for connected services. A security packet cannot be reviewed intelligently until the buyer states what the service will receive, create, change, and release.

Define the consequence too. Loss of a draft marketing image differs from unauthorized access to customer records. An unavailable preliminary layout differs from an unavailable system of record during permitting or construction. A changed proposal assumption differs from a changed technical release. The same feature can have different control needs depending on its position in the operating workflow.

Do not collapse the result into a decorative average. A platform may have strong evidence in several areas and still lack an export required for continuity, a role boundary needed for released work, or a contract answer required by the buyer. Record blocking conditions separately from improvements. Senior ownership should see what remains open and who can accept or resolve it.

The security decision has a shelf life. New features, vendors, integrations, data categories, locations, administrators, contract terms, or project uses can change the conclusion. Record the review date, scope, evidence versions, open actions, expiry or reassessment trigger, and owner.

Which solar project data and actions need protection?

Map every data category, credential, action, and dependent output in the proposed workflow. Include what enters, where it is processed or stored, who can access or change it, which services receive it, what leaves, and what must remain available. Classification belongs to the buyer’s qualified policy and review, not to a generic solar-software checklist.

An EPC data map often begins before design. Lead and customer records may include names, contact details, addresses, referral sources, bills, interval data, building photographs, financing discussions, and communications. Project work can add roof geometry, obstruction notes, module and inverter choices, production scenarios, financial assumptions, electrical material, proposal versions, approvals, comments, and external-review records.

Actions matter alongside information. Who may invite a user, change a role, share a project, replace an equipment choice, edit a model input, publish a proposal, export records, connect an application, or delete a workspace? A read-only exposure and an unauthorized release can have different consequences. Your map should connect each important action to a role, log, review, and recovery route.

NIST Special Publication 800-53 Revision 5 presents a broad catalog of security and privacy controls, including families for access, audit, contingency planning, incident response, personally identifiable information processing, acquisition, and system integrity. It is not a prescribed baseline for a private solar company or proof that a product meets the buyer’s needs.

NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk. Privacy and security overlap, but they are not interchangeable. A control can reduce unauthorized access while leaving purpose, collection, use, disclosure, retention, correction, or deletion questions unresolved. Keep privacy owners in the review.

Minimize test data. A buyer does not need to place a real household’s complete record into a vendor trial merely to see a screen. Use approved representative data and follow company policy for any personal, confidential, or regulated information. Record which material project conditions the sanitized test cannot prove.

Which security and data-ownership questions should buyers ask?

Ask twelve scoped questions covering data purpose, identity, privileged access, customer configuration, logging, recovery, incident handling, subprocessors, product security evidence, integrations, portable export, and deletion plus exit. For each answer, record the evidence, date, service scope, exclusions, buyer responsibility, contract dependency, reviewer, and unresolved item. Marketing language alone remains an unverified claim.

1. What information and actions are actually in scope?

Request a data-flow and function map for the intended configuration. Name categories, sources, purposes, storage or processing locations, recipients, retention paths, outputs, and administrative actions. Compare the vendor response with the buyer’s real workflow. If the buyer plans a use the vendor did not assess, the review has a scope gap.

2. How are users authenticated and roles separated?

Ask which authentication options exist, how accounts are provisioned and removed, whether administrator and ordinary roles differ, how project access is assigned, and which high-impact actions can be restricted. Do not assume a feature name proves correct configuration. Demonstrate the roles with test accounts and capture what each can view or change.

3. Who can exercise privileged or support access?

Identify vendor administrators, support personnel, subprocessors, emergency paths, approval controls, logging, time limits, and customer visibility. Ask how access is revoked when roles change. A statement that access is “limited” needs a definition, evidence scope, and responsible owner.

4. Which security settings belong to the customer?

The UK NCSC’s cloud security principles apply to SaaS and separately emphasize secure customer configuration. Ask which settings arrive by default, which the buyer must configure, who monitors drift, and how updates affect the baseline. Provider controls do not remove customer account, sharing, integration, device, or administrator responsibilities.

5. Which events are logged and available for review?

List the events needed for the use case: sign-in, failed authentication, invitation, role change, privileged access, sharing, export, deletion, integration changes, material project edits, and release actions where supported. Ask what is recorded, how long it is available, who can access it, how it can be exported, and what is absent.

6. What is backed up, and what has been tested for recovery?

Separate backup existence from recoverability. Ask which data and configuration are included, which are excluded, how dependencies affect recovery, what testing evidence is available, and which continuity work remains with the customer. Do not invent a recovery target. The responsible business and technical owners must define acceptable objectives for the intended process.

7. How will security events and incidents be handled?

Ask how suspected events are received, triaged, contained, investigated, communicated, and closed; which evidence is preserved; which contract terms control notice and cooperation; and which customer contacts stay current. CISA’s Cyber Essentials provides general leadership-oriented cybersecurity actions, not an incident plan for a vendor or EPC.

8. Which subprocessors, locations, and transfers are involved?

Request current subprocessor information and the services each party provides. Ask where relevant data may be processed, which changes trigger notice, and how the contract handles objections or termination. Location and transfer questions are legal and privacy matters for qualified review. Do not infer compliance from a region name.

9. What product-security evidence matches this service?

Ask about the development and vulnerability-management process, independent assessments or reports available under appropriate terms, evidence dates, service boundaries, exclusions, material findings, remediation handling, and customer notification. Never call a report a guarantee. Reviewers must determine whether it covers the product, environment, and configuration being evaluated.

CISA’s SCuBA project publishes configuration baselines and assessment tooling for Microsoft 365 and Google Workspace. It does not cover or certify solar software. It is a useful example of why a recognizable SaaS name and an actual configuration baseline are different evidence objects.

10. How are integrations, APIs, and service accounts controlled?

Inventory each connection, data field, direction, permission, credential owner, rotation or expiry process, log, failure signal, retry behavior, and offboarding step. Test a controlled failure. An integration that transfers data once may still fail silently later or retain broader access than the workflow requires.

11. Can the buyer export a usable project record?

Define portable before asking whether export exists. List project and object identifiers, structured fields, source references, files, attachments, revisions, comments, assumptions, approvals, logs available to the customer, and relationships that must survive. Export a representative project and reconcile it outside the platform. A PDF archive and a structured operational record serve different purposes.

12. What happens to access, retention, return, and deletion at exit?

“You own your data” does not explain operational control. Ask how long access continues, which formats are delivered, who assists, what costs or conditions apply, which records the provider retains, how deletion is requested and evidenced, how backups are handled, and which legal or contractual exceptions apply. Qualified reviewers must interpret the agreement.

The UK Technology Code of Practice includes security, privacy, integration, data use, purchasing, open standards, and lifecycle management in a government framework. It is not private solar procurement law. It supports one practical observation: the exit and data path belong in the original technology decision, not only in a termination ticket.

How should an EPC verify vendor answers before signing?

Verify vendor answers against a frozen intended-use record, current documents, configured test accounts, a representative project, controlled role changes, an integration failure, a recovery discussion, and an export opened outside the service. Record what was demonstrated versus asserted. Send legal, privacy, security, records, insurance, and technical questions to qualified owners before accepting risk.

Use a staged test so the evidence remains attributable:

1. Freeze scope and stop conditions. Record the service, configuration, data categories, user roles, integrations, output, consequences, required evidence, blocking gaps, and owners.

2. Build approved test material. Use representative but appropriately handled inputs, known exceptions, a material revision, role handoff, and expected export content.

3. Review current documents. Index every vendor artifact by title, date, service scope, issuer, confidentiality, limitation, reviewer, and contract dependency.

4. Configure and exercise roles. Create ordinary and administrative test users, change access, attempt prohibited actions, remove an account, and record observed behavior without treating one test as universal proof.

5. Exercise change and failure. Revise a consequential input, disconnect or fail an integration in a controlled manner, inspect alerts and recovery ownership, and reconcile dependent outputs.

6. Export and inspect independently. Open the delivered record outside the platform, compare identifiers and fields, inspect attachments and history, and name every omission or transformation.

7. Issue a written disposition. Choose approve, restricted use, remediation, pilot, defer, or reject. Assign open actions, compensating controls, exception expiry, reassessment triggers, and final authority.

Do not conduct unsafe testing against a production service. Penetration testing, scanning, traffic generation, credential testing, or attempts to bypass access can create harm and may violate agreements or law. Use vendor-authorized methods and qualified security professionals. Ordinary configured acceptance testing should remain inside the permitted environment and procedure.

Copy-ready solar software security review record

Use this operating record as a discussion structure, then adapt it through qualified review. Empty fields are unresolved. A completed worksheet is not a certification, legal conclusion, or substitute for inspecting the current evidence and agreement.

Keep vendor claims and buyer observations separate. “Role-based access is available” is a claim until the intended roles are configured and demonstrated. “Test user could not export the project” is an observation about one account and configuration, not proof that export never exists. Both need scope.

Illustrative example: a useful design export with missing history

This is an illustrative example, not a customer case, security assessment, breach, product result, or statement about SurgePV. An EPC evaluates a design and proposal service for a defined preliminary workflow. It uses approved representative data, two test roles, one administrator, a material equipment revision, and a required exit record.

The vendor provides current documents and demonstrates the normal workflow. The buyer creates and removes a test user, changes project sharing, records available logs, and exports the revised project. The export contains the current proposal and several structured fields, but it does not contain one category of decision history the buyer listed as required.

The team does not call the platform insecure. It records an exit-control gap. Legal and records owners check whether the missing history must be preserved elsewhere. The workflow owner decides whether a separate controlled record could meet the operating need. Procurement asks whether a different export or contractual service is available. Security reviews the access and logging evidence separately.

The final disposition is restricted pilot pending an accepted history-retention method and contract answer. Approval, remediation, defer, or rejection could also be valid with different evidence. The example shows how a specific gap becomes an owned decision without turning a checklist into a vendor ranking.

Where can SurgePV support the workflow, and where must qualified review take over?

SurgePV can explain and demonstrate its documented design and proposal scope and provide current product, security, privacy, operational, and contract information for review. The buyer must evaluate the intended configuration, accounts, integrations, data, evidence, agreements, and continuity requirements. Qualified owners decide security, privacy, legal, records, insurance, engineering, utility, and procurement matters.

SurgePV’s repository-verified public scope includes 3D roof modeling and array layout, shading analysis, energy-yield and financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. That scope defines solar workflow objects a buyer may test. It does not establish a security control, privacy position, data right, compliance result, or procurement approval.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation but do not replace approval by the responsible engineer, authority, lender, insurer, or utility. Current security features, data practices, hosting, subprocessors, service levels, implementation, support, pricing, and contract terms must be confirmed from current written evidence.

Use one project identifier across the test input, roof model, layout, modeled scenario, proposal, revision, and export. That makes it easier to check whether operational history remains intact. The buyer still owns its users, devices, sharing decisions, integration credentials, internal policy, approval workflow, and incident contacts to the extent assigned by the actual service and agreement.

Frequently Asked Questions

Does a security certification prove solar software is secure?

No single certificate or report proves security for every use. Buyers should verify the evidence type, issuer, date, service and system scope, exclusions, tested controls, findings, remediation status, and relationship to the configuration they will use. A qualified reviewer should interpret the evidence alongside customer-side responsibilities and current contract terms.

What does data ownership mean in a solar software contract?

Data ownership is a legal and contractual question that this guide cannot decide. Operationally, ask who may collect, access, use, disclose, correct, export, retain, return, and delete each data category, in which formats, under which terms, and after termination. Qualified legal, privacy, security, and records owners should review the actual agreement.

Which solar project information should a security review include?

Map every category the intended workflow will receive or create, including identities, contact details, addresses, imagery, bills, interval data, site records, designs, equipment, production and financial assumptions, proposals, contracts, comments, approvals, credentials, logs, and integration tokens. Classify it under the company’s current policy and applicable qualified review.

Should an EPC test data export before buying software?

Yes, when export and continuity matter to the intended use. Export a representative test project, open the files outside the platform, reconcile fields and identifiers, inspect attachments and revision history, and document omissions. The test proves only the selected scope and date, so contract rights and qualified retention, deletion, and transition review still matter.

Can SurgePV certify a buyer’s security or data-ownership position?

No. SurgePV can provide current product, security, privacy, contract, and operational information for qualified review, but the buyer must assess its own intended use, configuration, accounts, integrations, data, policies, agreements, and obligations. SurgePV’s verified public product scope does not itself establish security, compliance, ownership, suitability, or approval.

The strongest answer may be “not for this use yet.” That is not a procurement failure. It is a scoped decision with a route back when evidence, configuration, contract language, or operating controls change. Map the data, test the roles, open the export, preserve the gaps, and let qualified owners decide what the evidence supports.