Our application includes a default set of data. The default data includes coefficients and other factors that are unlikely to ever change but still need to be update-able by the user.
Currently, the original default data is stored as a populated class within the application. Data updates are stored to an external XML file. This design allows us to include a "reset" feature to restore the original default data. Our rationale for not storing defaults externally [e.g. XML file] was to minimize the risk of being altered. The overall volume of data doesn't warrant a database.
Is there a standard practice for storing "default" application data?
Suppose I were to answers: "Yes, there is a standard. 79% of systems worldwide externalise to a database." Would you now feel motivated to adopt a database? Surely not! Your particular requirements don't merit that overhead.
We're talking trade-offs here. Do the defaults need to change frequently? How much effort is it to change them using your current approach? Do you need to release different versions of the application with different defaults? Do the defaults change as you move from UAT to Production?
If you explore your requirements an engineering solution should emerge. In all likelyhood you will then make a better choice than the current common practice ("standard") that most folks have adopted, which all too often is to use whatever technique they used on their previous project.
For what it's worth, my personal "standard" is to externalise everything. Even when I don't expect things to change, sometime, somewhere, they do. Once I've decided to externalise then XML or property files doesn't make much difference to me.